Context Navigation

Changes between Version 5 and Version 6 of UnicodeInDjango

-              v5
+              v6
 Just a pin-down of things that spring to mind, all of them need more complete checking:
  * database backends need to handle unicode vs. DATABASE_ENCODING translations
+ * database backends need to handle unicode vs. DATABASE_CHARSET translations
  * special casing: the psycopg backend will need type handlers for string types (just as it already has type handlers for date/time types)
  * the HTTPResponse sending machinery needs to do the unicode to DEFAULT_ENCODING translation
  * the HTTPRequest creation process needs to turn outside strings into unicode strings, using the provided charset (if given) or defaulting to DEFAULT_ENCODING (as that is what was sent to the browser when the form was transmitted)
+ * the HTTPResponse sending machinery needs to do the unicode to DEFAULT_CHARSET translation
+ * the HTTPRequest creation process needs to turn outside strings into unicode strings, using the provided charset (if given) or defaulting to DEFAULT_CHARSET (as that is what was sent to the browser when the form was transmitted)
  * special casing: what happens with GET parameters? those don't provide charsets, what should we do if DEFAULT_ENCODING is utf-8, but the GET parameters aren't valid utf-8? The clean way would be to throw an exception (like with all other places, too)
  * internal usage of str() needs to be checked and supposedly changed over to unicode() usage