Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.044 X-Spam-Evidence: '*H*': 0.91; '*S*': 0.00; '*the': 0.09; 'escape': 0.09; 'sequences.': 0.09; 'python': 0.11; 'windows': 0.15; '...,': 0.16; '2.7.2': 0.16; 'idle,': 0.16; 'non-ascii': 0.16; 'repr()': 0.16; 'subject:Unicode': 0.16; 'file,': 0.19; 'print': 0.22; 'this?': 0.23; 'questions:': 0.24; 'stephen': 0.24; 'unicode': 0.24; 'received:209.85.214.174': 0.24; 'question': 0.24; 'characters': 0.30; 'message-id:@mail.gmail.com': 0.30; '(which': 0.31; 'tuples': 0.31; 'file': 0.32; 'text': 0.33; 'received:209.85': 0.35; 'objects': 0.35; 'received:google.com': 0.35; 'similar': 0.36; 'received:209': 0.37; 'skip:& 10': 0.38; 'displays': 0.38; 'to:addr:python-list': 0.38; 'that,': 0.38; 'to:addr:python.org': 0.39; 'even': 0.60; 'skip:u 10': 0.60; 'above,': 0.60; 'most': 0.60; 'skip:* 10': 0.61; 'such': 0.63; '(that': 0.65; 'here': 0.66; 'case?': 0.84; 'use\xa0': 0.84; 'whereas': 0.91 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=U4+7iHrTwyrTNi82amLiRL47VA2vLwp0XBj3nFGjKas=; b=Gm9PB9pifkV0vzKX8KgYbDUNobXEqOtgvjRnJwHbefBZUlz1OyiXlX68GwjKV74pXv xHLcg2QJj7JRtsaiul8vTy88JNQ7XKuzPxrKgh0yyy0mUG89Qb1Irn8+Ym9czKT60WZ9 ydpT88beWtlAzN0b8qyRKtcl5bcDbP//vqKnSsGAjgjJDn09TIUHUU+aPUxb0mxNKuRM F1ywMhocfXfthSN7bw8vd26qCvJCbQoCnD8L1Y8Gif4jtRkapOYCwfUoKx+4Ozor9CTh g9M4e/r3I7iymaiESBKuRN4Z3Z3GPpxiE3hmjp2SV41FtSXbIIHxrKh8rzHD93N4oC+p oj1Q== X-Gm-Message-State: ALoCoQncTlLnt7A2J8bHAnT1erPgeHowwu8ZUzIqz9WPwtG7iVCdwcK8u9DXVt3puSDcNH4A4rs8 MIME-Version: 1.0 X-Received: by 10.182.44.134 with SMTP id e6mr13274588obm.14.1381479396562; Fri, 11 Oct 2013 01:16:36 -0700 (PDT) Date: Fri, 11 Oct 2013 09:16:36 +0100 Subject: Unicode Objects in Tuples From: Stephen Tucker To: python-list@python.org Content-Type: multipart/alternative; boundary=001a11c3235ab26b2c04e872bc48 X-Mailman-Approved-At: Fri, 11 Oct 2013 10:17:39 +0200 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 58 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1381479460 news.xs4all.nl 15949 [2001:888:2000:d::a6]:52623 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:56657 --001a11c3235ab26b2c04e872bc48 Content-Type: text/plain; charset=ISO-8859-1 I am using IDLE, Python 2.7.2 on Windows 7, 64-bit. I have four questions: 1. Why is it that print unicode_object displays non-ASCII characters in the unicode object correctly, whereas print (unicode_object, another_unicode_object) displays non-ASCII characters in the unicode objects as escape sequences (as repr() does)? 2. Given that this is actually *deliberately *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? 3. A similar thing happens when I write such objects and tuples to a file opened by codecs.open ( ..., "utf-8") 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? 4. As for question 1 above, I ask here also: What is the neatest way to get round this? Stephen Tucker. --001a11c3235ab26b2c04e872bc48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am using IDLE, P= ython 2.7.2 on Windows 7, 64-bit.

I have four questions:<= br>

1. Why is it that
=A0=A0=A0=A0 print unicode_object
displays non-ASCII characters in the unicode object correctly, whereas
<= /div>=A0=A0=A0=A0 print (unicode_object, another_unicode_object)
d= isplays non-ASCII characters in the unicode objects as escape sequences (as= repr() does)?

2. Given that this is actually deliberately the case (whic= h I, at the moment, am finding difficult to accept), what is the neatest (t= hat is, the most Pythonic) way to get non-ASCII characters in unicode objec= ts in tuples displayed correctly?

3. A similar thing happens when I write such objects and tuples t= o a file opened by
=A0=A0=A0=A0 codecs.open ( ..., "utf-8")
I have also found that, even though I use=A0 write=A0 to send the te= xt to the file, unicode objects not in tuples get their non-ASCII character= s 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?

4. As for question 1 above, I ask here also: What is the neatest = way to get round this?

Stephen Tucker.

--001a11c3235ab26b2c04e872bc48--