[Python-Dev] Deprecate `from __future__ import unicode_literals`?
ncoghlan at gmail.com
Sat Dec 17 10:59:19 EST 2016
On 17 December 2016 at 21:58, Serhiy Storchaka <storchaka at gmail.com> wrote:
> On 17.12.16 13:44, Christian Heimes wrote:
>> On 2016-12-17 10:06, Serhiy Storchaka wrote:
>>> On 16.12.16 21:24, Guido van Rossum wrote:
>>>> e.g. the argument to getattr() -- I still hear of code that breaks due
>>>> to this occasionally)
>>> What is the problem with unicode in getattr()? Unicode attribute name is
>>> converted to str, and since the result is cached, this even don't add
>>> much overhead.
>> It breaks the str optimization of dicts. Dict with str-only keys are
>> special-cased in Python 2.
> getattr() converts a unicode to str and passes a str to PyObject_GetAttr().
getattr() may do the right thing, but directly accessing __dict__ doesn't.
python-future has a good write-up of the benefits and drawbacks, as they
originally recommended it unconditionally when modernising code, and
myself, Armin Ronacher, and a few others convinced them to be a little more
judicious in suggesting it to people:
However, that page also points out that whether or not it's likely to help
more than it hurts depends a lot on which version of Python you're starting
- if you're making originally Python 3 only code also work on Python 2, and
hence defining the first ever version of its Python 2 API, then you
probably *do* want to use unicode_literals, and then explicitly mark bytes
literals to get Python 2 working
- if you're modernising Python 2 code and have a lot of existing API users
on Python 2, then you probably *don't* want to use unicode_literals, and
instead explicitly mark your text literals as Unicode to get Python 3
In cases like Django where folks successfully adopted the
"unicode_literals" import for modernisation purposes, it was a matter of
aiming to get to that "Python 3 native, with Python 2 also supported"
structure as soon as possible (the fact that Django is structured primarily
as an object oriented framework likely helped with that, as it has a lot of
control over the data types user applications end up encountering).
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev