Re: Why deprecate the ability to reverse using the Python path?

[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

On 16 April 2015 at 09:33, Raphael Michel  wrote:

> Am Thu, 16 Apr 2015 01:21:04 -0700 (PDT)
> schrieb guettli :
> > 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
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at 

Re: Why deprecate the ability to reverse using the Python path?

[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

-- 
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 post to this group, send email to django-developers@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/508e21d3-a502-4e5a-a588-7da432431d93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why deprecate the ability to reverse using the Python path?

[Raphael Michel]

Am Thu, 16 Apr 2015 01:21:04 -0700 (PDT)
schrieb guettli :
> 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

-- 
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 post to this group, send email to django-developers@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.


pgpBXxZAuLhmG.pgp
Description: Digitale Signatur von OpenPGP

Re: Why deprecate the ability to reverse using the Python path?

[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

Am Mittwoch, 15. April 2015 10:19:47 UTC+2 schrieb 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.
>
>
>
>
>
>

-- 
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 post to this group, send email to django-developers@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/b6d682a8-0e2e-41db-9f01-d152624db79e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why deprecate the ability to reverse using the Python path?

[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 :-)



Am Mittwoch, 15. April 2015 12:51:25 UTC+2 schrieb 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().
>
> On Wednesday, April 15, 2015 at 4:19:47 AM UTC-4, guettli wrote:
>>
>> 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.
>>
>>
>>
>>
>>
>>

-- 
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 post to this group, send email to django-developers@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/7b026328-b554-46de-a324-59d18870c413%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why deprecate the ability to reverse using the Python path?

[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().

On Wednesday, April 15, 2015 at 4:19:47 AM UTC-4, guettli wrote:
>
> 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.
>
>
>
>
>
>

-- 
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 post to this group, send email to django-developers@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/a27d5e33-a016-4377-bc8b-ef214213aacb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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.





-- 
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 post to this group, send email to django-developers@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/4d36be10-847a-40f5-9421-5d6e0d6d865c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.