id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
23895	ResolverMatch with some views is not pickleable	Keryn Knight	zatro	"given something like the following:

{{{

def my_fbv(request):
    return HttpResponse('yay')

# urls.py
urlpatterns = [
    url('whatever', my_fbv, name='my_fbv'),
]
}}}

It is possible to do the following:
{{{
from django.core.urlresolvers import resolve
from pickle import dumps, loads
loads(dumps(resolve('whatever')))
}}}
and end up with a working `ResolverMatch`

However, given a Class Based View (mapped to a urlconf via `MyView.as_view()`), or something like contrib.admin, you get something like the following:
{{{
dumps(resolve('/admin/myapp/'))
[...]
# for the admin ...
PicklingError: Can't pickle <function app_index at 0x109f05de8>: it's not found as django.contrib.admin.sites.app_index
# for a CBV:
PicklingError: Can't pickle <function Homepage at 0x109f16b90>: it's not the same object as myapp.views.Homepage
}}}
Both of which are raised by pickle's `save_global(self, obj, name, pack)` which recognises that it's a module+name combo (thus should be in scope) but isn't the same object in identity (`if x is not y`)

Ordinarily, this is not a problem, but `resolver_match` is set onto a `request`, and I'm using the `django.test.client.Client` with multiprocessing, which requires the ability to pickle data to send back and forth, and evidently somewhere within the `TemplateResponse`s I'm dealing with, the request is being serialised (if I had to guess -- probably in the context) and is '''sometimes''' failing (depending on the type of view mounted)

Ideally, every `ResolverMatch` should be serialisable, or none should be, instead of the current situation where the project's urlconf may denote success or failure."	Bug	closed	Core (URLs)	4.0	Normal	fixed		django@…	Ready for checkin	1	0	0	0	0	0