#18974: Deprecate models.permalink
-------------------------------------+-------------------------------------
Reporter: dstufft | Owner: nobody
Type: | Status: new
Cleanup/optimization | Version: master
Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Design
Severity: Normal | decision needed
Keywords: | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by dstufft):
I think that if it doesn't get removed, at the very least it should
trigger some form of warning for any usage of it. Maybe a longer
deprecation process would be appropriate.
The code churn I think is overblown as it a easy change to make moving
from models.permalink to reverse and requires very little thought or
effort it likely even completely scriptable. It's not the first example of
deprecation of something that the removal provides "no benefit", other
similar examples would be:
1. Removal of `csrf_response_exempt()` and `csrf_view_exempt()`, one
of which was no-op and the other of which was a synonym for another
decorator.
2. `XMLField`, which was essentially a renamed `TextField` since the
oldforms removal, and is even seeing an accelerated removal.
3. Older ways of calling `page_cache` will be removed.
4. `django.conf.urls.defaults` will be removed in favor of
`django.conf.urls`
5. The old `setup_environ()` and `execute_manager()` functions will be
removed making any manage.py created pre 1.4 broken.
6. The compat shim of `HttpRequest.raw_post_body` will be removed as
it was a synonym for `HttpRequest.body`
Pretty much all of these have no harm, or little benefit for breaking
backwards compatibility (via the deprecation process) other than API
purity and having there be one way of doing something. Since the Permalink
decorator is basically a wrapper around reverse, numbers 1, 4, and 6 are
especially similar to this issue. I don't see a reason to keep around an
easily replaced decorator when the alternative is documenting "yea we have
this decorator, here's how to use it, but don't do that because it's bad".
* Note I don't mean to be snarky sounding (I feel like I am), I just don't
see how this is any different than any of these other changes, some of
which are going to cause issues on a *lot* of projects too.
--
Ticket URL: <https://code.djangoproject.com/ticket/18974#comment:12>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit https://groups.google.com/groups/opt_out.
