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
