Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!ecngs!feeder2.ecngs.de!novso.com!news.skynet.be!newsgate.cistron.nl!newsgate.news.xs4all.nl!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.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'encoding': 0.05; 'string.': 0.05; 'subject:Python': 0.06; '"""': 0.07; 'utf-8': 0.07; 'string': 0.09; 'absent': 0.09; 'ascii': 0.09; 'data:': 0.09; 'happen.': 0.09; 'null,': 0.09; 'pep': 0.09; 'strings.': 0.09; 'subject: [': 0.09; 'subject:string': 0.09; '"in': 0.16; 'absent,': 0.16; 'btw:': 0.16; 'created.': 0.16; 'differs': 0.16; 'encoding.': 0.16; 'expects': 0.16; 'from:addr:mrabarnett.plus.com': 0.16; 'from:addr:python': 0.16; 'from:name:mrab': 0.16; 'length)': 0.16; 'message- id:@mrabarnett.plus.com': 0.16; 'pairs': 0.16; 'pairs,': 0.16; 'received:84.93': 0.16; 'received:84.93.230': 0.16; 'surrogate': 0.16; 'typos': 0.16; 'wrote:': 0.18; 'obviously': 0.18; 'bit': 0.19; "python's": 0.19; 'version.': 0.19; '(in': 0.22; 'this?': 0.23; 'header:User-Agent:1': 0.23; 'pointer': 0.24; 'string,': 0.24; 'unicode': 0.24; 'question': 0.24; 'subject:/': 0.26; 'header:In-Reply-To:1': 0.27; 'function': 0.29; 'correct': 0.29; 'chris': 0.29; 'am,': 0.29; 'respective': 0.29; 'wonder': 0.29; "d'aprano": 0.31; 'minor': 0.31; 'steven': 0.31; 'file': 0.32; 'fri,': 0.33; 'sense': 0.34; 'could': 0.34; "can't": 0.35; 'created': 0.35; 'possible.': 0.35; 'received:84': 0.35; 'there': 0.35; 'surely': 0.36; 'should': 0.36; 'being': 0.38; 'subject:new': 0.38; 'to:addr:python-list': 0.38; 'issue': 0.38; 'does': 0.39; 'though,': 0.39; 'to:addr:python.org': 0.39; 'most': 0.60; 'length': 0.61; 'full': 0.61; 'field': 0.63; 'skip:n 10': 0.64; 'hang': 0.67; 'header:Reply-To:1': 0.67; 'mar': 0.68; 'reply-to:no real name:2**0': 0.71; 'power': 0.76; 'premature': 0.84; 'presumably': 0.84; 'reply-to:addr:python.org': 0.84; 'subject:long': 0.84; 'canonical': 0.91; 'cast': 0.91; '2013': 0.98 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=HO4d4PRv c=1 sm=1 a=0nF1XD0wxitMEM03M9B4ZQ==:17 a=B68SgI_Jlq8A:10 a=Ie5qI_Rfb9kA:10 a=ihvODaAuJD4A:10 a=OUOv7kDek9cA:10 a=8nJEP1OIZ-IA:10 a=EBOSESyhAAAA:8 a=8AHkEIZyAAAA:8 a=jgBMlathU_AA:10 a=kZ7UWmmPAAAA:8 a=oaChoSC0v3pL1advW1oA:9 a=wPNLvfGTeEIA:10 a=pyH5b1fOeEsA:10 a=gIJgMiF7CkbveIbj:21 a=qlZcoBMzjV46KNG9:21 a=0nF1XD0wxitMEM03M9B4ZQ==:117 X-AUTH: mrabarnett:2500 Date: Fri, 29 Mar 2013 02:00:24 +0000 From: MRAB User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: python-list@python.org Subject: Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] References: <5153a12d$0$29998$c3e8da3$5496439d@news.astraweb.com> <987c4bd9-0e5e-4387-9c78-1075a77d3c47@c6g2000yqh.googlegroups.com> <51543f45$0$29998$c3e8da3$5496439d@news.astraweb.com> <944f195c-cbfe-47e1-a963-05fe3d98238d@5g2000yqz.googlegroups.com> <5154e2dd$0$29974$c3e8da3$5496439d@news.astraweb.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: python-list@python.org 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: 56 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1364522420 news.xs4all.nl 6929 [2001:888:2000:d::a6]:33364 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:42212 On 29/03/2013 00:54, Chris Angelico wrote: > On Fri, Mar 29, 2013 at 11:39 AM, Steven D'Aprano > wrote: >> ASCII and Latin-1 strings obviously do not have them. Nor do BMP-only >> strings. It's only strings in the SMPs that could need surrogate pairs, >> and they don't need them in Python's implementation since it's a full 32- >> bit implementation. So where do the surrogate pairs come into this? > > PEP 393 says: > """ > wstr_length, wstr: representation in platform's wchar_t > (null-terminated). If wchar_t is 16-bit, this form may use surrogate > pairs (in which cast wstr_length differs form length). wstr_length > differs from length only if there are surrogate pairs in the > representation. > > utf8_length, utf8: UTF-8 representation (null-terminated). > > data: shortest-form representation of the unicode string. The string > is null-terminated (in its respective representation). > > All three representations are optional, although the data form is > considered the canonical representation which can be absent only while > the string is being created. If the representation is absent, the > pointer is NULL, and the corresponding length field may contain > arbitrary data. > """ > > If the string was created from a wchar_t string, that string will be > retained, and presumably can be used to re-output the original for a > clean and fast round-trip. Same with... > >> I also wonder why the implementation bothers keeping a UTF-8 >> representation. That sounds like premature optimization to me. Surely you >> only need it when writing to a file with UTF-8 encoding? For most >> strings, that will never happen. > > ... the UTF-8 version. It'll keep it if it has it, and not else. A lot > of content will go out in the same encoding it came in in, so it makes > sense to hang onto it where possible. > > Though, from the same quote: The UTF-8 representation is > null-terminated. Does this mean that it can't be used if there might > be a \0 in the string? > You could ask the same question about any encoding. It's only an issue if it's passed to a C function which expects a null-terminated string. > Minor nitpick, btw: >> (in which cast wstr_length differs form length) > Should be "in which case" and "from". Who has the power to correct > typos in PEPs? >