Usage of DjangoRuntimeWarning

[charettes]

During a review session I noticed the existence of `DjangoRuntimeWarning`[1]
which was introduced in order to be subclassed to warn about about cache keys
that are not compatible with Memcache[2].

As our test suite demonstrate subclassing `RuntimeWarning` can be quite useful
when you want to consider some of them as errors[3] or simply ignore them. I'm
sure some of you will remember the pesky naive datetime warnings that were
raised when using the SQLite3 backend with IPython when timezone support was
introduced.

While reviewing a proposed change where I suggested introducing another
`DjangoRuntimeWarning` just like we do with the cache key warning Claude noted
that we should always use such a patten or simply drop it[4] as a quick
`grep RuntimeWarning django -r` revealed the cache key warning was the only
occurence of `DjangoRuntimeWarning`.

While I don't think subclassing `DjangoRuntimeWarning` for every internal use of
`warnings.warn` is required I believe using `DjangoRuntimeWarning` instead of
`RuntimeWarning` would make sense.

Thoughts?

Simon

[1] https://github.com/django/django/blob/74675a15d04260e8def7303e1d7a1425b6043b6c/django/core/exceptions.py#L13-L14
[2] https://github.com/django/django/commit/fc26da645aea2361d78cf5a5543214a240d82527
[3] https://github.com/django/django/blob/master/tests/runtests.py#L25-L26
[4] https://github.com/django/django/pull/6384/files/49a9a4c522e7733be7dc9d3d3f66a422731898e9#r59893575

[Tim Graham]

I think warnings.filterwarnings(RuntimeWarning, module="django..") might allow filtering without a subclass?

According to the ticket, Carl offered the version of the patch with DjangoRuntimeWarning "following design discussion with Russell K-M, Malcolm T, Jannis L, and Jeremy Dunck." (in case any of them are reading this and remember the discussion from 6 years ago) [0].

[0] https://code.djangoproject.com/ticket/6447#comment:12