<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 17 December 2016 at 21:58, Serhiy Storchaka <span dir="ltr"><<a href="mailto:storchaka@gmail.com" target="_blank">storchaka@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 17.12.16 13:44, Christian Heimes wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 2016-12-17 10:06, Serhiy Storchaka wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 16.12.16 21:24, Guido van Rossum wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
e.g. the argument to getattr() -- I still hear of code that breaks due<br>
to this occasionally)<br>
</blockquote>
<br>
What is the problem with unicode in getattr()? Unicode attribute name is<br>
converted to str, and since the result is cached, this even don't add<br>
much overhead.<br>
</blockquote>
<br>
It breaks the str optimization of dicts. Dict with str-only keys are<br>
special-cased in Python 2.<br>
</blockquote>
<br></span>
getattr() converts a unicode to str and passes a str to PyObject_GetAttr().</blockquote><br></div><div class="gmail_quote">getattr() may do the right thing, but directly accessing __dict__ doesn't.<br><br></div><div class="gmail_quote">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: <a href="http://python-future.org/unicode_literals.html">http://python-future.org/unicode_literals.html</a><br><br></div><div class="gmail_quote">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:<br><br></div><div class="gmail_quote">- 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<br></div><div class="gmail_quote">- 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<br><br></div><div class="gmail_quote">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).<br></div><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Nick.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>