On Mon, Dec 15, 2014 at 4:42 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Devin Jeanpierre jeanpierr...@gmail.com writes:
On Sun, Dec 14, 2014 at 11:29 PM, Ben Finney ben+pyt...@benfinney.id.au
wrote:
from __future__ import unicode_literals
Ordinarily, for 2.x/3.3+ code I would suggest not doing this --
instead, b'...' for bytes, u'...' for unicode, and '...' for native
string type (bytes on 2.x, unicode on 3.x). This is the main benefit
of the u'...' syntax addition.
That latter point would seemingly also apply to ‘from __future__ import
unicode_literals’, so is moot in this context.
As for the advice to avoid such a declaration, you're arguing against
the official guide for porting Python 2 code to 2-and-3 compatible code:
For text you should either use the from __future__ import
unicode_literals statement or add a u prefix to the text literal.
URL:https://docs.python.org/3.4/howto/pyporting.html#text-versus-binary-data
So, the declarative import is specifically recommended. You'll need to
present a case for why I shouldn't follow that recommendation.
All the doc is saying there is to use unicode for text, in a way that
works in both 2.x and 3.x. I am saying that the unicode_literals
import is not necessarily the best way to do so.
Python has three categories of strings: things that should be bytes in
2.x and 3.x, things that should be unicode in 2.x and 3.x, and things
that should be bytes on 2.x and unicode on 3.x. The last category
applies mostly to identifiers -- the strings you pass to functions
like getattr or __import__, and the strings that are valid keys in
**kwargs, and so on. You need a way to represent the last kind of
string, whether it's unadorned ... literals, or function calls like
identifier_string(...). If you can solve that, you are good. The
official porting guide offers no advice.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
