Opened 4 years ago

Closed 4 years ago

#23070 closed Bug (fixed)

Instances of callable classes with __slots__ attributes in settings causes a failure to draw the 500 template

Reported by: colons Owned by: Hiroki Kiyohara
Component: Core (Other) Version: 1.7-rc-1
Severity: Release blocker Keywords:
Cc: Baptiste Mispelon, hirokiky@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

In a fresh django project, adding the following snippet to your settings files prevents the 500 page from rendering:

class Class(object):
    __slots__ = ['attr']

    def __init__(self, attr):
        self.attr = attr

    def __call__(self):
        pass

INSTANCE = Class(1)

The error that prevents the 500 error page from rendering is:

Traceback (most recent call last):
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/wsgiref/handlers.py", line 85, in run
    self.result = application(self.environ, self.start_response)
  File "venv/lib/python2.7/site-packages/django/contrib/staticfiles/handlers.py", line 64, in __call__
    return self.application(environ, start_response)
  File "venv/lib/python2.7/site-packages/django/core/handlers/wsgi.py", line 191, in __call__
    response = self.get_response(request)
  File "venv/lib/python2.7/site-packages/django/core/handlers/base.py", line 198, in get_response
    response = self.handle_uncaught_exception(request, resolver, sys.exc_info())
  File "venv/lib/python2.7/site-packages/django/core/handlers/base.py", line 241, in handle_uncaught_exception
    return debug.technical_500_response(request, *exc_info)
  File "venv/lib/python2.7/site-packages/django/views/debug.py", line 79, in technical_500_response
    html = reporter.get_traceback_html()
  File "venv/lib/python2.7/site-packages/django/views/debug.py", line 337, in get_traceback_html
    c = Context(self.get_traceback_data(), use_l10n=False)
  File "venv/lib/python2.7/site-packages/django/views/debug.py", line 315, in get_traceback_data
    'settings': get_safe_settings(),
  File "venv/lib/python2.7/site-packages/django/views/debug.py", line 65, in get_safe_settings
    settings_dict[k] = cleanse_setting(k, getattr(settings, k))
  File "venv/lib/python2.7/site-packages/django/views/debug.py", line 55, in cleanse_setting
    cleansed.do_not_call_in_templates = True
AttributeError: 'Class' object has no attribute 'do_not_call_in_templates

For me, this is a problem because I'm upgrading a project that stores what time of the week certain things happen with instances of dateutil's weekday object in the settings. Reproduced in 1.7c1 and current master, never happened in 1.6. I can probably work around it, but it'll be upsettingly inelegant.

Attachments (5)

do_not_call.zip (13.0 KB) - added by colons 4 years ago.
A project that exhibits this bug.
23070.diff (2.0 KB) - added by Hiroki Kiyohara 4 years ago.
23070_py2.png (2.7 KB) - added by Hiroki Kiyohara 4 years ago.
screen shot with py2
23070_py3.png (3.4 KB) - added by Hiroki Kiyohara 4 years ago.
screen shot with py3
23070_2.png (2.7 KB) - added by Hiroki Kiyohara 4 years ago.

Download all attachments as: .zip

Change History (14)

Changed 4 years ago by colons

Attachment: do_not_call.zip added

A project that exhibits this bug.

comment:1 Changed 4 years ago by Tim Graham

Could you bisect Django's history to the commit that introduced the change?

comment:2 Changed 4 years ago by anonymous

https://github.com/django/django/commit/3c5cdaf47aae7e4f21398be1a5eaa07f7c5ce31c

Would it be unreasonable to have cleanse_setting return a repr() or a str() (or unicode()) of the settings rather than the things themselves? That way it has direct control over whether or not they are called and doesn't have to rely on attempting to set attributes on objects that could be a type for all it knows.

comment:3 Changed 4 years ago by anonymous

Any object that cannot have the 'do_not_call_in_templates' attribute set on being set in settings will cause this issue, by the way; you can also cause it by using types or exceptions::

SCORE_NUMBER_TYPE = int
PASSABLE_EXCEPTION = ValueError

comment:4 Changed 4 years ago by Tim Graham

Cc: Baptiste Mispelon added
Component: UncategorizedCore (Other)
Severity: NormalRelease blocker
Triage Stage: UnreviewedAccepted

CCing Baptiste since he committed the change. Perhaps he can offer guidance.

comment:5 Changed 4 years ago by Hiroki Kiyohara

Owner: changed from nobody to Hiroki Kiyohara
Status: newassigned

trying

Changed 4 years ago by Hiroki Kiyohara

Attachment: 23070.diff added

Changed 4 years ago by Hiroki Kiyohara

Attachment: 23070_py2.png added

screen shot with py2

Changed 4 years ago by Hiroki Kiyohara

Attachment: 23070_py3.png added

screen shot with py3

comment:6 Changed 4 years ago by Hiroki Kiyohara

Cc: hirokiky@… added
Has patch: set

I added patch to solve it.
On this change it solve by using force_text instead of adding do_not_call_in_template.

And also I added screen shots when the patch is applied.

comment:7 Changed 4 years ago by Baptiste Mispelon

Patch needs improvement: set

This means that the debug page gives the wrong information (ADDED_CALLABLE is a function object but the page says it's a string).

We need to find a different approach.

comment:8 Changed 4 years ago by Hiroki Kiyohara

Patch needs improvement: unset

@bmispelon Thanks for the review
I fixed it and sent pull-request https://github.com/django/django/pull/2967.

Now the setting value appearing the debug page is valid.

Changed 4 years ago by Hiroki Kiyohara

Attachment: 23070_2.png added

comment:9 Changed 4 years ago by James Bennett <james@…>

Resolution: fixed
Status: assignedclosed

In 63058786882f6a32649a0fdafae9cb425c95cd4e:

Merge pull request #2967 from hirokiky/fix23070

Fixed #23070 -- not to break the debug page by callable setting with slots

Note: See TracTickets for help on using tickets.
Back to Top