Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder5.xlned.com!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.003 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'cpython': 0.05; 'string.': 0.05; 'subject:Python': 0.06; 'string': 0.09; 'compact': 0.09; 'feature.': 0.09; 'function:': 0.09; 'lookup': 0.09; 'pep': 0.09; 'received:80.91': 0.09; 'received:80.91.229': 0.09; 'received:gmane.org': 0.09; 'received:list': 0.09; 'sure,': 0.09; 'python': 0.11; 'stored': 0.12; 'opened.': 0.16; 'received:80.91.229.3': 0.16; 'received:plane.gmane.org': 0.16; 'url:gmane': 0.16; 'wrote:': 0.18; 'discussion': 0.18; 'thu,': 0.19; '>>>': 0.22; 'header:User-Agent:1': 0.23; 'bytes': 0.24; 'header': 0.24; 'mention': 0.26; 'post': 0.26; 'subject:/': 0.26; 'header:X-Complaints-To:1': 0.27; 'header:In-Reply-To:1': 0.27; 'chris': 0.29; 'feature': 0.29; 'url:bugs': 0.29; 'am,': 0.29; 'character': 0.29; "i'm": 0.30; "d'aprano": 0.31; 'intellectual': 0.31; 'steven': 0.31; 'url:se': 0.31; '(including': 0.33; 'url:python': 0.33; 'implemented': 0.33; 'agree': 0.35; 'something': 0.35; 'case,': 0.35; 'but': 0.35; 'really': 0.36; 'possible': 0.36; 'similar': 0.36; 'url:org': 0.36; 'should': 0.36; 'detail': 0.37; 'too': 0.37; '8bit%:86': 0.38; 'to:addr :python-list': 0.38; 'issue': 0.38; 'bad': 0.39; 'sure': 0.39; 'to:addr:python.org': 0.39; 'received:org': 0.40; 'future': 0.60; 'most': 0.60; 'simple': 0.61; 'different': 0.65; 'worth': 0.66; 'here': 0.66; 'determine': 0.67; 'request.': 0.70; 'apart': 0.72; 'bmp,': 0.84; "it'd": 0.84; 'pike': 0.84; 'subject:long': 0.84; 'versions)': 0.84; 'url:comments': 0.91; '2013': 0.98 X-Injected-Via-Gmane: http://gmane.org/ To: python-list@python.org From: Serhiy Storchaka Subject: Re: Performance of int/long in Python 3 Date: Sat, 06 Apr 2013 12:09:43 +0300 References: <87dff083-14d8-4163-89f3-d78a9be6c802@c15g2000vbl.googlegroups.com> <3qadncD4-6fcPsbMnZ2dnUVZ_rqdnZ2d@westnet.com.au> <515bbedb$0$29891$c3e8da3$5496439d@news.astraweb.com> <515be00e$0$29891$c3e8da3$5496439d@news.astraweb.com> <515c45ad$0$29966$c3e8da3$5496439d@news.astraweb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Gmane-NNTP-Posting-Host: 37.19.246.152 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 In-Reply-To: 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: 33 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1365275495 news.xs4all.nl 6917 [2001:888:2000:d::a6]:42614 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:42932 04.04.13 00:57, Chris Angelico написав(ла): > On Thu, Apr 4, 2013 at 2:07 AM, Steven D'Aprano > wrote: >> On Thu, 04 Apr 2013 01:17:28 +1100, Chris Angelico wrote: >> >>> Probably, but it still has to scan the body of the string. It'd not be >>> too bad if it's all astral, but if it's all BMP, it has to scan the >>> whole string. In the max() case, it has to scan the whole string anyway, >>> as there's no other way to determine the maximum. I'm thinking here of >>> this function: >>> >>> http://pike.lysator.liu.se/generated/manual/modref/ex/7.2_3A_3A/String/ >> width.html >>> >>> It's implemented as a simple lookup into the header. (Pike strings, like >>> PEP 393 strings, are stored in the most compact way possible - 1, 2, or >>> 4 bytes per character - with a conceptually similar header structure.) >>> Is this something that would be worth having available? Should I post an >>> issue about it? >> >> I'm not really sure why I would want to know, apart from pure >> intellectual curiosity, but sure, post a feature request. Be sure to >> mention that Pike supports this feature. > > http://bugs.python.org/issue17629 opened. See also the discussion at http://comments.gmane.org/gmane.comp.python.ideas/15640 . I agree with rejection. This is an implementation detail and different Python implementations (including future CPython versions) can have different internal string implementations.