Rename DEFAULT_CHARSET to OUTPUT_CHARSET (or similar)

[Simon Willison]

Just spotted this in the new unicode documentation (from the unicode branch):

Do not be fooled into thinking that if you DEFAULT_CHARSET setting is set
to something other than utf-8 you can use that encoding in your
bytestrings! The DEFAULT_CHARSET only applies to the strings generated as
the result of template rendering (and email). Django will always assume UTF-8
encoding for internal bytestrings. The reason for this is that the
DEFAULT_CHARSET setting is not actually under your control (if you are the
application developer). It is under the control of the person installing and
using your application and if they choose a different setting, your code must
still continue to work. Ergo, it cannot rely on that setting.

​http://code.djangoproject.com/browser/django/branches/unicode/docs/unicode.txt?rev=5330#L57

How about renaming that setting to something more clear, like OUTPUT_CHARSET or DEFAULT_OUTPUT_CHARSET?

[Marc Fargas <telenieko@…>]

+1 at least the setting will be a bit clearer on its purpose ;)
Maybe FILE_CHARSET could be moved to TEMPLATE_CHARSET as it only affects templates ;))

but you'd rather bring that to django-devs ;)

[Malcolm Tredinnick]

Well, that'll teach me to document things.

Might be worth changing for all the good reasons you mention. I thought about it, particularly when writing that passage, because it brings the unfortunate name into relief. On a theoretical level, I'm completely in agreement. But I hate making backwards incompatible changes. If we can fake a backwards compatible hack (e.g. populate OUTPUT_CHARSET from DEFAULT_CHARSET if the former doesn't exist in the settings module), I'd be happier. That's probably achievable, without thinking too hard about it.

I'm probably in favour, but I need some time to get used to it. :-)

Best plan of all: convince Adrian and/or Jacob so that I can avoid making a decision.

Marc: FILE_CHARSET was already discussed ad infinitum on django-dev. It's not going to change because it's not just used for template input (and that fact is even documented - look at the documentation for FILE_CHARSET in settings.txt).

[Jacob]

A bit of a wart, but I think I'm vaguely +0 on deprecating DEFAULT_CHARSET and switching to OUTPUT_CHARSET since Malcolm assures me that could be done in a backwards-compatible way.

[floguy]

Replaced all DEFAULT_CHARSET references with OUTPUT_CHARSET, and added PendingDeprecationWarnings for referencing DEFAULT_CHARSET.

[ctrochalakis]

replace-DEFAULT_CHARSET

[floguy]

That second patch is cleaner than my first one.

[ctrochalakis]

replace-DEFAULT_CHARSET+deprecation warning

[ctrochalakis]

Added a deprecation warning as Eric did in the first patch. The warning is triggered if the DEFAULT_CHARSET is set.

[Malcolm Tredinnick]

At a minimum there needs be a "New in Django develpoment version" marker in the settings documentation. I'd also leave a docs entry in place for DEFAULT_CHARSET and refer it to OUTPUT_CHARSET with a note that this was the older way of doing it. That way people reading the docs and searching for the setting they have in their code will still find an entry.

[ctrochalakis]

Added a "new in development version" marker. Also, DEFAULT_CHARSET section in retained in the settings.txt file, and refers to OUTPUT_CHARSET.

[Malcolm Tredinnick]

Not worth it now. We're going to have to support DEFAULT_CHARSET for a long time now that 1.0 is coming out and it doesn't seem to be causing a lot of confusion to people. Yes, I probably should have just fixed this when it was first raised, but I didn't. Sorry, but can't go back in time (time machine is only for bug fixes, not a cure for sloth).