Opened 13 years ago
Closed 12 years ago
#18054 closed Cleanup/optimization (fixed)
deprecate contrib.markup
| Reported by: | Preston Holmes | Owned by: | nobody |
|---|---|---|---|
| Component: | contrib.markup | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | yes |
| Easy pickings: | no | UI/UX: | no |
Description
A recent security issue (#17837) and then bug (#17994) in the markdown library has been a reminder that Django is not a markup framework, but a web framework and should continue shedding contrib modules that are:
- not core to the usage of the framework
- poorly tested
- poorly documented
(list not comprehensive)
following the logic and pattern for the deprecation of databrowse #16907 - I'm suggesting that contrib.markup be deprecated for 1.5
Change History (8)
comment:1 by , 13 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:3 by , 13 years ago
I agree as well. Accelerated deprecation for contrib.markup is a solid move.
follow-up: 5 comment:4 by , 12 years ago
| Has patch: | set |
|---|---|
| Version: | 1.4 → master |
comment:5 by , 12 years ago
| Patch needs improvement: | set |
|---|
Replying to timo:
Thanks for the patch.
A couple minor notes:
Paul is suggesting an accelerated deprecation timeline which I think does make sense - this would mean that the warning is a DeprecationWarning - not a PendingDeprecationWarning
Also, in each case where you are communicating the deprecation - it is often useful to provide a very brief suggestion such as "use the 3rd party Python markup libraries directly"
A note needs to be added to:
docs/internals/deprecation.txt
Note that if the deprecation is accelerated - it should be noted explicitly as accelerated under the 1.6 section (and release notes)
Finally - and this is subjective perhaps, I wouldn't inject the points about general philosophy as to why something is deprecated for this particular example, as we wouldn't repeat that for each deprecation.
However there is some good communication about deprecation philosophy in this ticket, and it might be worth adding to somewhere else in the docs - perhaps the release process doc
comment:7 by , 12 years ago
Here is an update to the patch
https://github.com/ptone/django/compare/django:master...deprecate-markup-18054
comment:8 by , 12 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
In particular, contrib modules where Django adds little value (writing a project-specific version of any one of its filters is a three or four line exercise) but gets a lot of exposure to "responsibility" for bugs and security issues in third-party packages. contrib.markup fits that bill exactly.
Accepting.