Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed2.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.030 X-Spam-Evidence: '*H*': 0.94; '*S*': 0.00; 'subject:PEP': 0.07; '#define': 0.09; '-looking': 0.09; 'happen?': 0.09; 'implements': 0.09; 'pep': 0.09; 'analysing': 0.16; 'called.': 0.16; 'literals': 0.16; 'means.': 0.16; 'received:65.55.116.7': 0.16; 'specifier': 0.16; 'str.format()': 0.16; 'wrote:': 0.18; 'thu,': 0.19; 'written': 0.21; 'to:name:python-list@python.org': 0.22; 'received:65.55.116': 0.24; 'header': 0.24; 'source': 0.25; 'mention': 0.26; 'skip:_ 20': 0.27; 'header:In-Reply-To:1': 0.27; 'skip:- 40': 0.29; 'patch': 0.29; '???': 0.30; 'code': 0.31; 'date:': 0.34; 'maybe': 0.34; 'skip:d 20': 0.34; "can't": 0.35; 'definition': 0.35; 'but': 0.35; 'really': 0.36; '+0100': 0.36; "i'll": 0.36; 'error.': 0.37; 'so,': 0.37; 'turn': 0.37; 'email addr:python.org': 0.37; 'to:addr:python-list': 0.38; 'skip:_ 30': 0.39; 'explain': 0.39; 'subject:': 0.39; "couldn't": 0.39; 'to:addr:python.org': 0.39; 'how': 0.40; 'even': 0.60; 'email addr:gmail.com': 0.63; 're:': 0.63; 'happen': 0.63; 'email name :python-list': 0.65; 'compiles': 0.84; 'optimisation': 0.84; 'oscar': 0.84; 'carlos': 0.91; 'relating': 0.93; '2013': 0.98 X-TMN: [67HEYDH4WnvVAIlYN/+z6ve+rBukVIAK] X-Originating-Email: [carlosnepomuceno@outlook.com] From: Carlos Nepomuceno To: "python-list@python.org" Subject: RE: PEP 378: Format Specifier for Thousands Separator Date: Thu, 23 May 2013 03:44:36 +0300 Importance: Normal In-Reply-To: References: , , , , <519c348a$0$6599$c3e8da3$5496439d@news.astraweb.com> <519C3D99.5040107@gmail.com>, <519cdcff$0$6599$c3e8da3$5496439d@news.astraweb.com>, <87eaaf24-df6a-4f6b-b873-16ca96c12e24@b2g2000yqe.googlegroups.com>, , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 May 2013 00:44:36.0889 (UTC) FILETIME=[B3615890:01CE574E] 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: 60 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1369269883 news.xs4all.nl 15909 [2001:888:2000:d::a6]:47686 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:45765 ----------------------------------------=0A= > From: oscar.j.benjamin@gmail.com=0A= > Date: Thu=2C 23 May 2013 01:30:53 +0100=0A= > Subject: Re: PEP 378: Format Specifier for Thousands Separator=0A= > To: carlosnepomuceno@outlook.com=0A= > CC: pruebauno@latinmail.com=3B python-list@python.org=0A= >=0A= > On 22 May 2013 23:31=2C Carlos Nepomuceno = wrote:=0A= >>=0A= >> I still don't understand why % benefits from literals optimization ("'%d= '%12345") while '{:d}'.format(12345) doesn't.=0A= >=0A= > There's no reason why that optimisation can't happen in principle.=0A= > However no one has written a patch for it. Why don't you look into=0A= > what it would take to make it happen?=0A= >=0A= >=0A= > Oscar=0A= =0A= Maybe I'll look into that later=2C but I couldn't even find how the hell th= ey made _Py_InsertThousandsGrouping() been called.=0A= =0A= That's what I got when analysing % formating:=0A= =0A= Thousands separator format specifier for str.__mod__()=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=0A= =0A= @Objects/stringobject.c: implements formatint() for '%' processing=0A= -Looking for code used in str.format()=0A= =0A= @Objects/stringlib/formatter.h: implements str.format()=0A= -It uses STRINGLIB_GROUPING() to do the job.=0A= =0A= @Objects/stringlib/stringdefs.h: #define STRINGLIB_GROUPING=A0=A0=A0=A0=A0= =A0 _PyString_InsertThousandsGrouping=0A= @Objects/stringlib/unicodedefs.h: #define STRINGLIB_GROUPING=A0=A0=A0=A0=A0= =A0 _PyUnicode_InsertThousandsGrouping=0A= @Objects/stringobject.c: #define _Py_InsertThousandsGrouping _PyString_Inse= rtThousandsGrouping=0A= @Objects/stringobject.h: declares _PyString_InsertThousandsGrouping()=0A= @???: ??? _PyString_InsertThousandsGrouping ??? _Py_InsertThousandsGrouping= =0A= @Objects/stringlib/localeutil.h: implements _Py_InsertThousandsGrouping()= =0A= =0A= =0A= Let me explain what that means. I found no relating declarations/definition= s that turn _PyString_InsertThousandsGrouping into _Py_InsertThousandsGroup= ing.=0A= =0A= So=2C I don't even know how that source code compiles without error.=0A= =0A= :/ really strange...=0A= =0A= =0A= Not to mention the lots of code inside header definition files! Weird!!!! = =