[Python-Dev] Deprecate `from __future__ import unicode_literals`?

[Nick Coghlan]

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:
http://python-future.org/unicode_literals.html

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
from:

- 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
working

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).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161218/d35e843c/attachment-0001.html>