#28029 closed Uncategorized (invalid)
Removal of ability to reverse by dotted path found to be very non-DRY
Reported by: | Henrik Levkowetz | Owned by: | nobody |
---|---|---|---|
Component: | Core (URLs) | Version: | 1.10 |
Severity: | Normal | Keywords: | |
Cc: | felisiak.mariusz@… | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I've been using django for the site datatracker.ietf.org
for about 10 years now, updating to new Django releases along the way. I've almost always appreciated the features of each new release, but release 1.10 brought this feature removal:
- The ability to reverse() URLs using a dotted Python path is removed. (https://docs.djangoproject.com/en/1.10/releases/1.10/#features-removed-in-1-10)
The site (datatracker.ietf.org) has about 750 distinct URL patterns, and we've been very good at referencing URLs using {% url %}
in our templates, and using django.url.reverse()
in code. Given that the dotted url names previously provided gave a consistent DRY way of referring to the URL belonging to a given view function, we used it extensively.
This means that in order to upgrade to 1.10 I was suddenly faced with the task of manually naming ~750 URL patterns with unique and meaningful names, and potentially updating many thousands of places using reverse URL lookup in code and templates, for no apparent benefit.
The ticket which removed reversal by dotted path, #22384, also removed the ability to refer to view functions by strings in url()
. To be clear: This ticket is not about that change. I found that a bit inconvenient, and it seems to me that it increases the risk of import loops, but that change is not what I'm contesting here; it's only the removal of the built-in ability to reverse by dotted path that I find very non-DRY.
In the end I replaced django.conf.urls.url()
with a wrapper that generated a dotted-url-path name based on the view function, which mostly restored the pre-1.10 functionality; but having to do that seems to me to be very contrary to the batteries-included approach we're proud of.
Change History (3)
comment:1 by , 8 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 by , 8 years ago
I'm sorry if I tried to point out what I feel is a mistake in the wrong place, by opening a ticket and referring back to the earlier ticket. I had considered posting to the dev list, but when one of the core developers with whom I talked at DjangoCon Europe (happening right now) suggested I open a ticket about the matter, I did so.
I have read the thread you pointed out, and I don't find a rationale for removing the reversal by dotted path there. What I find is a conflation of the two different issues mentioned in #22384. Everything seems to hinge on Marc Tamlyn's statements in his final post on that short thread, where he says "Firstly, it relies on automatic imports via strings, ..." , which seems to associate the dotted-path-reversal change with the ability to naming view functions by strings in url()
.
However, removing automatic import via strings is orthogonal to the ability to support reversal by dotted, path, as evidenced by the ability to write a custom url()
function the way I did, and the way originally suggested by you (Tim).
My immediate problem is solved, but the harm I feel is done to Django by the removal of the ability to do reversal by the dotted path of the view function is not. Forcing people to re-invent new names for something that already has a clear and definitive name is not supporting DRY, quite the opposite.
So, what now? Is your (Tim) advice to take this up on the dev mailing list trumping the earlier advice from a core developer to submit a ticket? How can I open a discussion of this issue which will receive consideration?
comment:3 by , 8 years ago
Sorry for the confusion. Design decisions happen on the mailing list rather than on the ticket tracker. As I said before, it's not really useful to open a ticket that has no clear plan of action. A concrete solution needs to be proposed, along with a considering of backwards compatibility, etc.
The rationale is explained in more detail on the developers mailing list. You may continue the conversation there, but the ticket tracker isn't the place to raise inactionable feedback like this. If the conversation on the mailing list reveals a consensus to make some change, we would open a ticket at that point.