Why deprecate the ability to reverse using the Python path?

[guettli]

Today I realized that the ability to reverse using the Python path gets deprecated

My source: https://docs.djangoproject.com/en/1.8/ref/urlresolvers/#reverse

Imagine you have a very clear directory structure and everyone knows this in
your company.

The name of an url pattern is redundant. I like to avoid redundancy (DRY).

I don't see the reasons behind this.

The security issues are already solved: https://www.djangoproject.com/weblog/2014/apr/21/security/#s-issue-unexpected-code-execution-using-reverse

Please tell me the reason.

One work around this would be to give each view the name of the import path: name="common_structure.foo.bar"
And if you don't allow dots: name="common_structure/foo/bar"
But this looks not dirty.

[Tim Graham]

Please see the ticket and release notes:
https://code.djangoproject.com/ticket/22384
https://docs.djangoproject.com/en/1.8/releases/1.8/#passing-a-dotted-path-to-reverse-and-url

If you want to continue using dotted paths, you might be able to create a custom url() function that assigns a name using the view's path and use that in your urlpatterns instead of django.conf.urls.url().

[guettli]

Thank you Graham. I will talk with my team mates again.

Moving  to URLs with names is no good solution for us. But maybe using the view methods itself.

Since a lazy reverse() exists since some releases now, removing the whole string magic might be a good idea.

Thanks to all django developers for your constant updates. It's just hard to keep up with your pace :-)

[guettli]

Dear Graham and django developers,

I talked about this in our team. The pace is to fast. We have about thousand urls mappings
that need to be changed to from reverse('mapp.views.foo.bar') to reverse(view_method).

We never jumped on the "give the URLs a name" wagon.

What do you gain be disabling this feature? Security is not a concern any more.

We think disabling this feature brings drawbacks without advantage.

Related topic:

Using classed_based_view_instance.url instead of reverse(classed_based_view_instance)
would be nice. What do you think?

Quote from ticket 22384
{{{
Marc mentioned in that ticket "Reversing by dotted path to view is just a bad idea."
}}}

Maybe it was a bad idea. It was a bad since reverse() was not lazy many versions ago.
This created recursive import errors reverse() got called during importing a python file.

Again: Please think about this decision again. I guess many people don't want to reformat
their code base just because some said it was "just a bad idea".

Regards,
  Thomas Güttler

[Raphael Michel]

Am Thu, 16 Apr 2015 01:21:04 -0700 (PDT)
schrieb guettli <h...@tbz-pariv.de>:

> We never jumped on the "give the URLs a name" wagon.

Why don't you go with Tim's idea to implement a custom url() method to
automatically give the views their path as URL names? This should be
rather easy and you should be able to do the migration in half an our
without any drawbacks.

Best regards,
Raphael

[Florian Apolloner]

Hi Thomas,

On Thursday, April 16, 2015 at 10:21:04 AM UTC+2, guettli wrote:

I talked about this in our team. The pace is to fast.

FWIW, every feature changed/deprecated goes through the same (fast) cycle. If you need slower changes, please stay with LTS versions. Granted, you still have to change your code at some point, but not that rapidly…

We have about thousand urls mappings that need to be changed to from reverse('mapp.views.foo.bar') to reverse(view_method).

You can just write your own url() which sets this as name, all the reverses can stay the same

What do you gain be disabling this feature? Security is not a concern any more.

A single codepath and nicer error handling, ie you'd get a normal python import error when the import in urls.py failed. Before that Django often masked errors in the string import mechanism etc…
 

We think disabling this feature brings drawbacks without advantage.

Clear and understandable error messages that are thrown at the point where they should have been is a big adventage for me personally (and from my experience in #django, many people welcomed that change :))

Cheers,
Florian

[Marc Tamlyn]

Hi Thomas,

I appreciate your concern, and it's a significant change for your application, which is obviously very large and has been in development for some time. I've been involved with similarly painful processes such as the transition to the {% url %} tag requiring a string.

First a note on the pace: Django urls have had names since at least Django 1.1, I can't find docs for them before that. We have been recommending the use of url names in the tutorial and everywhere else in the documentation since Django 1.5. We could have deprecated it at the same time as we did this, but chose to delay that by a couple of years. When we then proposed it for deprecation, a newer contributor expressed surprise that the feature actually existed, as it hasn't been prominent in the documentation for some time.

The feature has just been deprecated now, it will not be removed until Django 2.0, at least a year from now. Django 1.8 is also an LTS, so you can rely on that for at least 3 years if you need to.

Regarding the motivation for the change, I should expand on why I think it's a bad idea. For the sake of clarity, when I say it's "just a bad idea", I mean "I cannot find a redeeming feature for this idea, it's just plain bad".

Firstly, it relies on automatic imports via strings, something Django has done far too much of historically and we are trying to move away from. In settings it is hard to avoid, elsewhere it pays to be more explicit. We have addressed some security concerns in this area, but that does not mean that they are all avoided. Secondly, It restricts your ability to move views around, especially in a third party application. If you decide your views file needs splitting up, you have to then reimport everything into the init.py or rewrite all the reversing. In the prototyping phase of a new project, I've often found  It's an unnecessary level of coupling for most applications, with very little work to avoid it. Thirdly, the whole feature doesn't work for class based views which are now in common usage throughout a lot of the Django ecosystem, and having a shortcut which only works for a part of the system doesn't make sense. Finally, it makes overriding urls from external packages a huge amount harder. With naming, you can deliberately override the name and url pattern of a given view, and anything pointing at the old one will now point at yours.

The general consensus in conversations held in person or on IRC was that naming was a far better design decision and probably should have been enforced from the start. There were at least 6 members of the core team involved in the decision at the time, two of them on the technical board. We don't consider "give URLs a name" to be a wagon, we consider it to be the only correct way to do it.

In terms of what you can do, you have a few options. The first proposal is a good one by Tim, to implement a custom url() or patterns() function in your project which infers either by using the passed string or inspecting the actual function where the view lives, and constructs the name `myapp.views.foo` out of it. This means a small piece of code to write, and a small change in each of your urls.py files. Another alternative is to update all your urls.py to add the name `myapp.views.foo`. If you've got 1000 url mappings this is a bit of work, although depending on how succinctly formatted your files are you can probably mostly do it with sed. This was your original suggestion. There aren't any restrictions on the name of a url except that it probably shouldn't contain `:` as that is used for namespaced url patterns.

A more complete solution would be to define your own new project convention. It seems something like `myapp-foo` would suit you well. This would require more work to update, although again large chunks of the work could be done with sed. Your exact mileage may vary.

In summary, we feel that it enforces good practice, at a relatively small upgrade cost for existing sites who use the "old" way. It simplifies the code, and removes some unpleasant side effects. I hope this explanation helps.

Marc

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20150416103313.79d5f25d%40kvothe.

For more options, visit https://groups.google.com/d/optout.