Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!rt.uk.eu.org!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.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'remind': 0.05; 'represents': 0.05; 'string.': 0.05; 'subject:Python': 0.06; 'extent': 0.07; 'modify': 0.07; 'users,': 0.07; 'utf-8': 0.07; 'string': 0.09; 'arrays': 0.09; 'ascii': 0.09; 'bytes.': 0.09; 'character,': 0.09; 'converts': 0.09; 'false.': 0.09; 'strings.': 0.09; 'subject: [': 0.09; 'api': 0.11; 'python': 0.11; '*always*': 0.16; '[*]': 0.16; 'benjamin': 0.16; 'character.': 0.16; 'corresponds': 0.16; 'cp1252': 0.16; 'did.': 0.16; 'encodings': 0.16; 'endian': 0.16; 'from:addr:mrabarnett.plus.com': 0.16; 'from:addr:python': 0.16; 'from:name:mrab': 0.16; 'internally': 0.16; 'inverse': 0.16; 'invisible': 0.16; 'message- id:@mrabarnett.plus.com': 0.16; 'only)': 0.16; 'received:84.93': 0.16; 'received:84.93.230': 0.16; 'safely.': 0.16; 'situation.': 0.16; 'stuff.': 0.16; 'subject: \n ': 0.16; 'truncate': 0.16; 'truncation': 0.16; 'unicode.': 0.16; 'variants': 0.16; 'wrote:': 0.18; 'pointed': 0.19; "python's": 0.19; 'thu,': 0.19; 'user.': 0.19; '(the': 0.22; 'memory': 0.22; 'coding': 0.22; 'putting': 0.22; 'saying': 0.22; 'header:User-Agent:1': 0.23; 'byte': 0.24; 'bytes': 0.24; 'case.': 0.24; 'oriented': 0.24; 'sorry,': 0.24; 'unicode': 0.24; 'java': 0.24; 'non': 0.24; 'regardless': 0.24; "i've": 0.25; 'source': 0.25; 'define': 0.26; '----------': 0.26; 'subject:/': 0.26; 'defined': 0.27; 'header:In-Reply-To:1': 0.27; 'point': 0.28; 'function': 0.29; 'am,': 0.29; 'array': 0.29; 'character': 0.29; 'characters': 0.30; 'especially': 0.30; "i'm": 0.30; 'code': 0.31; 'decimal': 0.31; '-----': 0.33; 'actual': 0.34; 'could': 0.34; 'problem': 0.35; 'one,': 0.35; 'point.': 0.35; 'prepare': 0.35; 'received:84': 0.35; 'but': 0.35; 'there': 0.35; 'version': 0.36; 'european': 0.36; 'scheme': 0.36; 'possible': 0.36; 'application': 0.37; 'step': 0.37; 'being': 0.38; 'implement': 0.38; 'represent': 0.38; 'product.': 0.38; 'subject:]': 0.38; 'to:addr:python-list': 0.38; 'previous': 0.38; 'little': 0.38; 'explain': 0.39; 'does': 0.39; 'to:addr:python.org': 0.39; 'enough': 0.39; 'either': 0.39; 'major': 0.40; 'how': 0.40; 'ensure': 0.60; 'even': 0.60; 'algorithms': 0.60; 'consists': 0.60; 'ian': 0.60; 'length': 0.61; 'mentioned': 0.61; 'new': 0.61; 'range': 0.61; 'simply': 0.61; "you're": 0.61; 'discuss': 0.62; 'back': 0.62; 'soon': 0.63; 'valuable': 0.63; 'became': 0.64; 'map': 0.64; 'therefore,': 0.64; 'more': 0.64; 'charset:windows-1252': 0.65; 'between': 0.67; 'header:Reply-To:1': 0.67; 'mar': 0.68; 'wish': 0.70; 'reply-to:no real name:2**0': 0.71; 'further,': 0.74; 'characters,': 0.84; 'divide': 0.84; 'dry': 0.84; 'examples.': 0.84; 'irrelevant': 0.84; 'reply-to:addr:python.org': 0.84; 'subject:long': 0.84; 'western': 0.86; '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=d5osE0Bd0hoA:10 a=ihvODaAuJD4A:10 a=OUOv7kDek9cA:10 a=N659UExz7-8A:10 a=EBOSESyhAAAA:8 a=8AHkEIZyAAAA:8 a=ZSPP0T9P_JwA:10 a=pGLkceISAAAA:8 a=Hm2Oo-_KcwTwIvWiitkA:9 a=pILNOxqGKmIA:10 a=MSl-tDqOz04A:10 a=JGs2HBQ9vcIC0_RZ:21 a=Nkih4O7cLwSSqj9i:21 a=0nF1XD0wxitMEM03M9B4ZQ==:117 X-AUTH: mrabarnett:2500 Date: Thu, 28 Mar 2013 21:50:14 +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: 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> <7f993624-8105-4055-a268-3417e5fe21dc@g4g2000yqd.googlegroups.com> <691c604c-b643-4d66-a2ea-c5c52d603316@c6g2000yqh.googlegroups.com> In-Reply-To: <691c604c-b643-4d66-a2ea-c5c52d603316@c6g2000yqh.googlegroups.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: 102 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1364507414 news.xs4all.nl 6964 [2001:888:2000:d::a6]:49367 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:42196 On 28/03/2013 21:11, jmfauth wrote: > On 28 mar, 21:29, Benjamin Kaplan wrote: >> On Thu, Mar 28, 2013 at 10:48 AM, jmfauth wrote: >> > On 28 mar, 17:33, Ian Kelly wrote: >> >> On Thu, Mar 28, 2013 at 7:34 AM, jmfauth wrote: >> >> > The flexible string representation takes the problem from the >> >> > other side, it attempts to work with the characters by using >> >> > their representations and it (can only) fails... >> >> >> This is false. As I've pointed out to you before, the FSR does not >> >> divide characters up by representation. It divides them up by >> >> codepoint -- more specifically, by the *bit-width* of the codepoint. >> >> We call the internal format of the string "ASCII" or "Latin-1" or >> >> "UCS-2" for conciseness and a point of reference, but fundamentally >> >> all of the FSR formats are simply byte arrays of *codepoints* -- you >> >> know, those things you keep harping on. The major optimization >> >> performed by the FSR is to consistently truncate the leading zero >> >> bytes from each codepoint when it is possible to do so safely. But >> >> regardless of to what extent this truncation is applied, the string is >> >> *always* internally just an array of codepoints, and the same >> >> algorithms apply for all representations. >> >> > ----- >> >> > You know, we can discuss this ad nauseam. What is important >> > is Unicode. >> >> > You have transformed Python back in an ascii oriented product. >> >> > If Python had imlemented Unicode correctly, there would >> > be no difference in using an "a", "é", "€" or any character, >> > what the narrow builds did. >> >> > If I am practically the only one, who speakes /discusses about >> > this, I can ensure you, this has been noticed. >> >> > Now, it's time to prepare the Asparagus, the "jambon cru" >> > and a good bottle a dry white wine. >> >> > jmf >> >> You still have yet to explain how Python's string representation is >> wrong. Just how it isn't optimal for one specific case. Here's how I >> understand it: >> >> 1) Strings are sequences of stuff. Generally, we talk about strings as >> either sequences of bytes or sequences of characters. >> >> 2) Unicode is a format used to represent characters. Therefore, >> Unicode strings are character strings, not byte strings. >> >> 2) Encodings are functions that map characters to bytes. They >> typically also define an inverse function that converts from bytes >> back to characters. >> >> 3) UTF-8 IS NOT UNICODE. It is an encoding- one of those functions I >> mentioned in the previous point. It happens to be one of the five >> standard encodings that is defined for all characters in the Unicode >> standard (the others being the little and big endian variants of >> UTF-16 and UTF-32). >> >> 4) The internal representation of a character string DOES NOT MATTER. >> All that matters is that the API represents it as a string of >> characters, regardless of the representation. We could implement >> character strings by putting the Unicode code-points in binary-coded >> decimal and it would be a Unicode character string. >> >> 5) The String type that .NET and Java (and unicode type in Python >> narrow builds) use is not a character string. It is a string of >> shorts, each of which corresponds to a UTF-16 code point. I know this >> is the case because in all of these, the length of "\u1f435" is 2 even >> though it only consists of one character. >> >> 6) The new string representation in Python 3.3 can successfully >> represent all characters in the Unicode standard. The actual number of >> bytes that each character consumes is invisible to the user. > > ---------- > > > I shew enough examples. As soon as you are using non latin-1 chars > your "optimization" just became irrelevant and not only this, you > are penalized. > > I'm sorry, saying Python now is just covering the whole unicode > range is not a valuable excuse. I prefer a "correct" version with > a narrower range of chars, especially if this range represents > the "daily used chars". > > I can go a step further, if I wish to write an application for > Western European users, I'm better served if I'm using a coding > scheme covering all thesee languages/scripts. What about cp1252 [*]? > Does this not remind somthing? > > Python can do better, it only succeeds to do worth! > > [*] yes, I kwnow, internally .... > If you're that concerned about it, why don't you modify the source code so that the string representation chooses between only 2 bytes and 4 bytes per codepoint, and then see whether that you prefer that situation. How do the memory usage and speed compare?