On 9/21/07, Brian Harring <[EMAIL PROTECTED]> wrote: > The only spot I can see this potentially causing issues is for > the 'literal' fast pathing, since it just reuses what was passed in- > forcing that to unicode in __init__ ought to resolve that. If it's > something other then that, definitely after examples.
That's mostly what I was thinking about; right now if you pass a Unicode string into a Variable, and it contains non-ASCII-compatible characters, then you can make the Variable blow up by invoking anything that hits its __str__ or that makes assumptions about 'var'; the Variable class just works with the provided string as-is, never checking what sort of string it is. I'm still not sure what the best way to work around this is. I'm leaning toward using one of the utility encoding functions to coerce the string to Unicode fairly early on (e.g., in __init__), but I don't yet know enough about the implications to figure out where the safest place to do that is. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
