Dictionary update sequence element # 0 has a length of 15; 2 required

This is because the render_to_response () as well as render () shortcuts will automatically apply the RequestContext to the context variables (dir variables). This is a typo for sure, but why did it work before asking?

This would have worked prior to 1.6, but the implementation of RequestContext in django.template.context changed in 1.7. It has been broken down to be more object oriented and optimized to make it more efficient. The story is here, I think it was

https://github.com/django/django/commits/master/django/template/context.py

This is a commit, in particular of the optimized RequestContext:

https://github.com/django/django/commit/8d473b2c54035cbcd3aacef0cb83a9769cd05ad3

Here's how to make the mistake again:

>>> from django.template import RequestContext
>>> from django.test.client import RequestFactory
>>> request_factory = RequestFactory()
>>> request = request_factory.get('www.google.com')
>>> fresh_data_locations, webalert_locations, reporting_locations, locations_not_reporting, inalarm_count, inalarm_stores_qs, workspace_count, user_profile = '', '', '', '', '', '', '', ''
>>> variables = RequestContext(request, {
...     'fresh_locations': fresh_data_locations,
...     'webalert_locations': webalert_locations,
...     'locations_reporting': reporting_locations,
...     'locations_not_reporting': locations_not_reporting,
...     'inalarm_count': inalarm_count,
...     'inalarm_stores': inalarm_stores_qs,
...     'workspace_count': workspace_count,
...     'user_profile': user_profile,
... })
>>> variables
[{'False': False, 'None': None, 'True': True}, {'workspace_count': '', 'locations_not_reporting': '', 'fresh_locations': '', 'inalarm_stores': '', 'locations_reporting': '', 'webalert_locations': '', 'user_profile': '', 'inalarm_count': ''}, {u'csrf_token': <django.utils.functional.__proxy__ object at 0x10439fcd0>, u'sql_queries': [], 'perms': <django.contrib.auth.context_processors.PermWrapper object at 0x10439fe50>, 'messages': [], u'request': <WSGIRequest
path:/www.google.com,
GET:<QueryDict: {}>,
POST:<QueryDict: {}>,
COOKIES:{},
META:{u'HTTP_COOKIE': u'',
 u'PATH_INFO': u'www.google.com',
 u'QUERY_STRING': '',
 u'REMOTE_ADDR': '127.0.0.1',
 u'REQUEST_METHOD': 'GET',
 u'SCRIPT_NAME': u'',
 u'SERVER_NAME': 'testserver',
 u'SERVER_PORT': '80',
 u'SERVER_PROTOCOL': 'HTTP/1.1',
 u'wsgi.errors': <_io.BytesIO object at 0x1042fce30>,
 u'wsgi.input': <django.test.client.FakePayload object at 0x104391550>,
 u'wsgi.multiprocess': True,
 u'wsgi.multithread': False,
 u'wsgi.run_once': False,
 u'wsgi.url_scheme': 'http',
 u'wsgi.version': (1, 0)}>, 'api_header': {'content-type': 'application/json', 'Authorization': 'YmFrZXItYXBpOlVuaW9uMTIz'}, u'STATIC_URL': '/static/', u'LANGUAGES': (('en', 'English'),), 'api_address': 'http://69.164.69.214/BakerPublic/api', 'user': <django.contrib.auth.models.AnonymousUser object at 0x10439fe10>, u'LANGUAGE_CODE': u'en-us', u'debug': True, 'DEFAULT_MESSAGE_LEVELS': {'DEBUG': 10, 'INFO': 20, 'WARNING': 30, 'SUCCESS': 25, 'ERROR': 40}, u'LANGUAGE_BIDI': False, u'MEDIA_URL': '/media/'}]
>>> type(variables)
<class 'django.template.context.RequestContext'>
>>> dict(variables)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
ValueError: dictionary update sequence element #0 has length 15; 2 is required

      

        
        
        
      

    

So django 1.6's dir () function returns without error, but with execution of 1.7 it fails. Only one of those things that you worked with can say almost coincidence up to 1.7.

When using classes based on django.views.generic, many of these things are simply done for you. If you look at the TemplateView, you can see that it inherits the render_to_response method from TemplateResponseMixin, which uses TemplateResponse, which does all of this. Also check out ContextMixin which has get_context_data method. The cleanest way, in my opinion, is to pass context data to the template. More on generic views / classes here .