> Some examples:
Thanks for posting them:
> >>> Template(u"{{ foo }}").render(Context({"foo":"bar"}))
> u'bar'
I get
py> Template("{{ foo }}").render(Context({b"foo":b"bar"}))
''
I think that's correct: the dictionary has no key "foo".
I'm also unsure what this has to do with UTF-8: isn't this the regular
default encoding (ASCII) that allows you to have Unicode and byte
strings compare equal?
What is the syntax for variable names (i.e. can you even have non-
ASCII characters in variable names)?
> >>> Template("{{ foo }}").render(Context({u"foo":"bar"}))
> u'bar'
py> Template(b"{{ foo }}").render(Context({"foo":b"bar"}))
'bar'
Not sure why this happens - perhaps variable names get always
converted into strings?
> >>> Template("{{ foo }}").render(Context({"foo":u"bar"}))
> u'bar'
py> Template(b"{{ foo }}").render(Context({b"foo":"bar"}))
''
Also notice that it never produces bytes in these cases. Again, I'm
unsure why this happens.
> >>> MyModel.objects.filter(my_attr="foo")
py> Choice.objects.filter(choice=b'geht so')
[<Choice: geht so>]
> >>> MyModel.objects.filter(my_attr=u"foo")
py> Choice.objects.filter(choice='geht so')
[<Choice: geht so>]
> >>> mymodel_instance.my_attr = "foo"
> >>> mymodel_instance.my_attr = u"foo"
>>> c=Choice()
>>> c.choice=b'fine'
>>> c.choice='fine'
>
> In addition to these things, there may be problems where dictionary
> keys and various other values have used byte strings up until now,
> with no problems, but based on assumptions that no longer hold. For
> example, declarative classes (e.g. Models) are an interesting one -
> inPython2.x, the keys of MyClass.__dict__ are byte strings, but in 3.0,
> they are unicode strings. Since non-ascii names for identifiers are
> valid inPython3.0 (thanks in part, I believe, to your good self :-),
> and also in at least some databases, this is not an academic issue.
Not sure what issue you see here. It's most likely difficult to map
such names into a relational database. Having a restriction that
requires field names to follow SQL syntax sounds reasonable to me.
As for __dict__ now containing Unicode strings - this already had a
number of consequences on the patch. My recommendation would be that
identifier-like things always get represented as (unicode) strings in
Django on 3k (or more generally, by the "standard" string type).
> Also, inPython3.0, you can have models with non-ascii names, which
> challenges some assumptions about things like the INSTALLED_APPS
> setting.
Again, I don't see a need to support these. I doubt the ability to
create them would be the primary reason why people would switch to
Python 3...
> I imagine that some of these things will 'come out in the wash', so to
> speak, and the lack of automatic conversion will help identify
> problems, but some things might come back to bite us if we don't get
> them right.
I think migration of existing applications is probably the biggest
challenge. For a new 3.x application, the guideline should be to use
the (unicode) string type throughout, and leave encodings entirely to
Django.
Regards,
Martin
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
