Path: csiph.com!usenet.pasdenom.info!news.albasani.net!newsfeed.freenet.ag!news2.euro.net!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; 'skip:[ 20': 0.03; 'explicitly': 0.04; 'say,': 0.05; 'sys': 0.05; '64-bit': 0.07; 'ascii': 0.07; 'strings.': 0.07; 'suppose': 0.07; 'python': 0.09; '40,': 0.09; '75,': 0.09; 'bytes)': 0.09; 'pep': 0.09; 'pointers': 0.09; 'received:80.91': 0.09; 'received:80.91.229': 0.09; 'received:gmane.org': 0.09; 'received:list': 0.09; 'subject:string': 0.09; 'typedef': 0.09; 'aug': 0.13; '39,': 0.16; '42,': 0.16; '46,': 0.16; '52,': 0.16; '54,': 0.16; 'bit.': 0.16; 'build.': 0.16; 'build?': 0.16; 'convey': 0.16; 'py_ssize_t': 0.16; 'received:80.91.229.3': 0.16; 'received:dip.t-dialin.net': 0.16; 'received:plane.gmane.org': 0.16; 'received:t-dialin.net': 0.16; 'subject:3.3': 0.16; 'wrote:': 0.17; 'bytes': 0.17; 'char': 0.17; '>>>': 0.18; 'import': 0.21; '(on': 0.22; 'constant': 0.22; 'struct': 0.22; 'linux': 0.24; 'header:User-Agent:1': 0.26; 'embedded': 0.27; 'header:X-Complaints-To:1': 0.28; 'skip:( 20': 0.28; '50,': 0.29; "d'aprano": 0.29; 'overhead': 0.29; 'steven': 0.29; "i'm": 0.29; 'that.': 0.30; '(from': 0.30; '(2)': 0.32; 'not.': 0.32; 'structure': 0.32; 'getting': 0.33; '+0200,': 0.33; 'to:addr:python-list': 0.33; 'formats': 0.35; 'received:org': 0.36; 'explain': 0.36; 'skip:p 20': 0.36; 'does': 0.37; 'uses': 0.37; 'why': 0.37; 'subject:New': 0.37; 'data': 0.37; 'subject:: ': 0.38; 'sure': 0.38; 'to:addr:python.org': 0.39; 'where': 0.40; 'header:Received:5': 0.40; 'your': 0.60; 'system)': 0.61; 'more': 0.63; '81,': 0.84; 'maths': 0.84; 'otten': 0.84; '74,': 0.91 X-Injected-Via-Gmane: http://gmane.org/ To: python-list@python.org From: Peter Otten <__peter__@web.de> Subject: Re: New internal string format in 3.3 Date: Sun, 19 Aug 2012 11:37:09 +0200 Organization: None References: <308df2af-abe7-4043-b199-0a39f440e0ab@googlegroups.com> <502f8a2a$0$29978$c3e8da3$5496439d@news.astraweb.com> <4c62a649-bc21-4e47-9c0f-acb1b1e70e36@googlegroups.com> <5030891f$0$29978$c3e8da3$5496439d@news.astraweb.com> <5030aa44$0$29978$c3e8da3$5496439d@news.astraweb.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Gmane-NNTP-Posting-Host: p50849f38.dip.t-dialin.net User-Agent: KNode/4.7.3 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.12 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: 47 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1345369039 news.xs4all.nl 6901 [2001:888:2000:d::a6]:60860 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:27369 Steven D'Aprano wrote: > On Sun, 19 Aug 2012 09:43:13 +0200, Peter Otten wrote: > >> Steven D'Aprano wrote: > >>> I don't know where people are getting this myth that PEP 393 uses >>> Latin-1 internally, it does not. Read the PEP, it explicitly states >>> that 1-byte formats are only used for ASCII strings. >> >> From >> >> Python 3.3.0a4+ (default:10a8ad665749, Jun 9 2012, 08:57:51) [GCC >> 4.6.1] on linux >> Type "help", "copyright", "credits" or "license" for more information. >>>>> import sys >>>>> [sys.getsizeof("é"*i) for i in range(10)] >> [49, 74, 75, 76, 77, 78, 79, 80, 81, 82] > > Interesting. Say, I don't suppose you're using a 64-bit build? Because > that would explain why your sizes are so larger than mine: > > py> [sys.getsizeof("é"*i) for i in range(10)] > [25, 38, 39, 40, 41, 42, 43, 44, 45, 46] > > > py> [sys.getsizeof("€"*i) for i in range(10)] > [25, 40, 42, 44, 46, 48, 50, 52, 54, 56] Yes, I am using a 64-bit build. I thought that >> (2) Latin1 strings have a constant overhead of 24 bytes (on a 64bit >> system) over ASCII-only. would convey that. The corresponding data structure typedef struct { PyASCIIObject _base; Py_ssize_t utf8_length; char *utf8; Py_ssize_t wstr_length; } PyCompactUnicodeObject; makes for 12 extra bytes on 32 bit, and both Py_ssize_t and pointers double in size (from 4 to 8 bytes) on 64 bit. I'm sure you can do the maths for the embedded PyASCIIObject yourself.