<div dir="ltr"><div><div><div>A quick reply to all you contributors (by the way, I was not expecting to get so many responses so quickly - I am (as you probably realise) new to this kind of thing.<br><br></div>I am stuck with Python 2.X because ESRI's ArcGIS system uses it - otherwise, yes, you're all right, I would be in Python 3.X like a shot! So that rules out any answers to my questions that involve Python 3.X. (Sorry, perhaps I should have mentioned that at the outset - as I say, I'm new to all this.)<br>
<br></div>ESRI compound the problem, actually, by making all the strings that the ArcGIS Python interface delivers (from MS SQLServer) Unicode! (I suppose, on reflection, they have no choice.) So I am stuck with the worst of both worlds - a generation of Python (2.X) that is inept at handling unicode (on an operating system (MS Windows 7) that is not much better, and being flooded with unicode strings from my users' databases! Anything you can come up with to ease all this (like, "convert <i>all</i> your strings to unicode as soon as you can and render them as ASCII as late as you can") has already been of help.<br>
<br></div>On the original question, well, I accept Ned's answer (at 10.22). I also like the idea of a helper function given by Peter Otten at 09.51. It still seems like a crutch to help poor old Python 2.X to do what any programmer (or, at least the programmers like me :-) ) think it ought to be able to by itself. The distinction between the "geekiness" of a tuple compared with the "non-geekiness" of a string is, itself, far too geeky for my liking. The distinction seems to be an utterly spurious - even artificial or arbitrary one to me. (Sorry about the rant.)<br>
<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 11, 2013 at 10:22 AM, Ned Batchelder <span dir="ltr"><<a href="mailto:ned@nedbatchelder.com" target="_blank">ned@nedbatchelder.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
On 10/11/13 4:16 AM, Stephen Tucker wrote:<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>I am using IDLE, Python 2.7.2 on Windows 7,
64-bit.<br>
</div>
<div><br>
I have four questions:<br>
</div>
<div><br>
1. Why is it that<br>
print unicode_object<br>
</div>
displays non-ASCII characters in the unicode
object correctly, whereas<br>
</div>
print (unicode_object, another_unicode_object)<br>
</div>
displays non-ASCII characters in the unicode objects
as escape sequences (as repr() does)?<br>
<br>
</div>
2. Given that this is actually <i>deliberately </i>the
case (which I, at the moment, am finding difficult to
accept), what is the neatest (that is, the most
Pythonic) way to get non-ASCII characters in unicode
objects in tuples displayed correctly?<br>
<br>
</div>
3. A similar thing happens when I write such objects and
tuples to a file opened by<br>
codecs.open ( ..., "utf-8")<br>
</div>
I have also found that, even though I use write to send
the text to the file, unicode objects not in tuples get
their non-ASCII characters sent to the file correctly,
whereas, unicode objects in tuples get their characters sent
to the file as escape sequences. Why is this the case?<br>
<br>
</div>
4. As for question 1 above, I ask here also: What is the
neatest way to get round this?<br>
<br>
</div>
Stephen Tucker.<br>
<br>
</div>
</blockquote>
<br></div></div>
Although Python 3 is better than Python 2 at Unicode, as the others
have said, the most important point is one that you hit upon
yourself.<br>
<br>
When you print an object x, you are actually printing str(x). The
str() of a tuple is a paren, followed by the repr()'s of its
elements, separated by commas, then a closing paren. Tuples and
lists use the repr() of their elements when producing either their
own str() or their own repr().<br>
<br>
Python 3 does better at this because repr() in Python 3 will gladly
include non-ASCII characters in its output, while Python 2 will only
include ASCII characters, and so must resort to escape sequences.
(BTW: if you like the ASCII-only idea from Python 2, Python 3 has
the ascii() function and the %a string formatting directive for that
very purpose.)<br>
<br>
The two string representation alternatives str() and repr() can be
confusing. Think of it as: str() is for customers, repr() is for
developers, or: str() is for humans, repr() is for geeks. The
reason tuples use the repr() of their elements is that the
parens+commas representation of a tuple is geeky to begin with, so
it uses repr() of its elements, even for str(tuple).<br>
<br>
The way to avoid repr() for the elements is to format the tuple
yourself.<span class="HOEnZb"><font color="#888888"><br>
<br>
--Ned.<br>
</font></span></div>
</blockquote></div><br></div>