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 <[email protected]> wrote:
> Am Thu, 16 Apr 2015 01:21:04 -0700 (PDT)
> schrieb guettli <[email protected]>:
> > 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 [email protected].
> To post to this group, send email to [email protected].
> 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.
>
--
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 [email protected].
To post to this group, send email to [email protected].
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/CAMwjO1HP%2Bmg%2BYcDwiCt50bSdr%3D86ksBJjYgf59j07KnWi4%3D5JA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
