Hi, ak schrieb: > After some thoughts I came to the following conclusion: if you guys > want to keep support of legacy charsets in fact you don't have to > force model objects too be unicoded. Firstly, they are passed to > templates and filters and we can't mix legacy charsets with unicode in > one template. Next, if I don't use unicode, I don't have to code my > python sources (views) in unicode. So, I need to be able to pass > string values into my model objects and my strings are not unicoded. > > So if everyone agreed, the way is simple: > 1. when django loads data from db and fills in a model object, all > strings have to be encoded according to DEFAULT_CHARSET > 2. when django passes data from form object to model object, it has to > encode strings according to DEFAULT_CHARSET again
This thread is moving more and more away the tickets. I started it to get some help in deciding how to proceed with these ... Regarding ak's proposal, this is going against a widely shared agreement within the python world that applications should internally use unicode strings (not: utf8 strings) and decode/encode to a bytestring at the boundaries, which is usually input/output, or for database applications it's the communication between the database backend (e.g. MySQLdb) and the database. I'm not in a position to make any decisions for django, but I'm pretty sure that you cannot convince the core developers to follow your path. Down to earth and back to tickets, my current understanding is this: The problem that started the original thread in django-users was that the MySQLdb backend thought it was using latin-1 encoding for the connection and therefore could not encode '', which is in iso-8859-15 but not in iso-8859-1 aka iso-latin-1. Ticket #2896 seems to explain how this can happen. In my opinion, each of the three tickets in the subject should solve this issue, and none tries to cope with templates written in a different encoding than settings.DEFAULT_ENCODING. #952 allows to use a different encoding on the connection than settings.DEFAULT_CHARSET. It does it for all backends. #1365 sets connection.charset in the mysql backend to utf8. This makes the MySQLdb use utf8 encoding, but it's hackish and has been reported not to work in all environments. #3370 opens the mysql backend connection with charset='utf8', which seems a cleaner way to do the same as #1365. It also fixes the __repr__ of models (not sure if this is the best way, but this can be added to any of the other patches) My bottom line is that #952 has a different scope than the other two tickets, and that #1365 should be closed as duplicate of #3370. #3370 and #952 can co-exist. So, would anybody object against closing #1365 and promoting #952 and #3370 to "Accepted" (which was their state before we started this discussion)? Michael --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
