On Dec 16, 2016, at 01:07 PM, Ethan Furman wrote:

On 12/16/2016 11:24 AM, Guido van Rossum wrote:

...

I am beginning to think that `from __future__ import unicode_literals` does more harm than good. I don't recall exactly why we introduced it, but with the restoration of u"" literals in Python 3.3 we have a much better story for writing straddling code that is unicode-correct.

So cross-version code would be primarily 2.7 and 3.3+ ? I can live with that.

So can I. I don't mind "silently" deprecating it, such as adding strong admonitions against its use in the docs, but clearly it can't be removed (at least until 3.7) and I worry about breaking existing code, even with a more chatty DeprecationWarning. At least in some circles, the problems of unicode_literals are known, but it's still useful and it's used in lots of places. Getting rid of cruft like this is one of the more satisfying edits when dropping Python 2 support. :) Cheers, -Barry

On 16 Dec 2016, at 16:07, Ethan Furman wrote:

On 12/16/2016 11:24 AM, Guido van Rossum wrote:

...

I am beginning to think that `from __future__ import unicode_literals` does more harm than good. I don't recall exactly why we introduced it, but with the restoration of u"" literals in Python 3.3 we have a much better story for writing straddling code that is unicode-correct.

So cross-version code would be primarily 2.7 and 3.3+ ? I can live with that.

Speaking for third-party library authors, almost all cross-version code that does anything remotely close to a network is 2.7 and 3.3+. Requests dropped 3.2 support basically as soon as we could once 3.3’s unicode literals were restored, and since then I haven’t written anything that targets 3.2. It’s just too frustrating. And while I’m shoving my oar in, I’ve never seen anyone be happy with using “from __future__ import unicode_literals”. As others in this thread have said, it just points a loaded gun at your foot and lets you wait for it to go off. Cory

I've actually found unicode_literals useful in getting code to be Python 2/3-compatible. I try to use a Python 3-like model of always using unicode for text data and only using str for binary data, and unicode_literals helps achieve that, since most string literals are meant to be text, not binary data. The issue with functions like getattr is annoying, but in my experience it's not a common problem (I don't often call getattr() with a string literal as an argument). 2016-12-16 14:56 GMT-08:00 Raymond Hettinger :

...

On Dec 16, 2016, at 11:24 AM, Guido van Rossum wrote:

I am beginning to think that `from __future__ import unicode_literals` does more harm than good. I don't recall exactly why we introduced it, but with the restoration of u"" literals in Python 3.3 we have a much better story for writing straddling code that is unicode-correct.

The problem is that the future import does both too much and not enough -- it does too much because it changes literals to unicode even in contexts where there is no benefit (e.g. the argument to getattr() -- I still hear of code that breaks due to this occasionally) and at the same time it doesn't do anything for strings that you read from files, receive from the network, or even from other files that don't use the future import.

I wonder if we can add an official note to the 2.7 docs recommending against it? (And maybe even to the 3.x docs if it's mentioned there at all.)

+1 Leaving it in place will likely cause more problems than it solves, so I think your suggest is a net win even if there is some bit of disruption. Also, as far as I can tell, the adoption rate of Python 3.2 was very low. Python 3's story didn't become attractive until later.

Raymond _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ jelle.zijlstra%40gmail.com

On Fri, Dec 16, 2016 at 3:52 PM, Matěj Cepl wrote:

I don’t understand.

No need to get all bent out of shape. My proposal is to simply add a note to the docs recommending against using this. I wouldn't change any code, not even a silent deprecation warning. (Also, read the rest of the thread to learn why this is not the best practice for writing Python 2/3 straddling code.) -- --Guido van Rossum (python.org/~guido)

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

On Mon, Dec 19, 2016 at 11:50 PM, Chris Barker wrote:

Please don't get rid of unicode+literals -- I don't even think we should depreciate it as a recommendation or discourage it.

Maybe a note or two added as to where issues may arise would be good.

I've found importing unicode_literals to be an excellent way to write py2/3 code. And I have never found a problem.

I'm also hoping that my py2/3 compatible code will someday be py3 only -- and then I'll be really glad that I don't have all those u" all over the place.

Also it does "automagically" do the right thing with, for instance passing a literal to the file handling functions in the os module -- so that's pretty nice.

The number of times you need to add a b"" is FAR fewer than "text" string literals. Let's keep it.

-CHB

Same thing here... also, it helps coding with the same mindset of Python 3, where everything is unicode by default -- and yes, there are problems if you use a unicode in an API that accepts bytes on Python 2, but then, you can also have the same issues on Python 3 -- you need to know and keep track on the bytes vs unicode everywhere (although they're syntactically similar to declare, they're not the same thing) and I find that there are less places where you need to put b'' than u'' (if you code with unicode in mind in Python 2)... On the ideal world, Python 2 would actually be improved to accept unicode on the places where Python 3 accepts unicode (such as subprocess.Popen, etc) to make it easier in porting applications that actually do the "right" thing on Python 2 to go to Python 3. Best Regards, Fabio​