Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #45686 > unrolled thread

Re: PEP 378: Format Specifier for Thousands Separator

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: PEP 378: Format Specifier for Thousands Separator Andrew Berg <bahamutzero8825@gmail.com> - 2013-05-21 14:53 -0500
    Re: PEP 378: Format Specifier for Thousands Separator Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-22 02:59 +0000
      Re: PEP 378: Format Specifier for Thousands Separator Andrew Berg <bahamutzero8825@gmail.com> - 2013-05-21 22:38 -0500
      Re: PEP 378: Format Specifier for Thousands Separator Skip Montanaro <skip@pobox.com> - 2013-05-22 05:45 -0500
        Re: PEP 378: Format Specifier for Thousands Separator Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-22 14:58 +0000
          Re: PEP 378: Format Specifier for Thousands Separator Ned Batchelder <ned@nedbatchelder.com> - 2013-05-22 14:30 -0400
            Re: PEP 378: Format Specifier for Thousands Separator nn <pruebauno@latinmail.com> - 2013-05-22 13:26 -0700
              RE: PEP 378: Format Specifier for Thousands Separator Carlos Nepomuceno <carlosnepomuceno@outlook.com> - 2013-05-23 01:31 +0300
                Re: PEP 378: Format Specifier for Thousands Separator nn <pruebauno@latinmail.com> - 2013-05-23 06:44 -0700
                  RE: PEP 378: Format Specifier for Thousands Separator Carlos Nepomuceno <carlosnepomuceno@outlook.com> - 2013-05-23 18:26 +0300
                  Re: PEP 378: Format Specifier for Thousands Separator Dave Angel <davea@davea.name> - 2013-05-23 14:42 -0400
                    Re: PEP 378: Format Specifier for Thousands Separator nn <pruebauno@latinmail.com> - 2013-05-24 06:50 -0700
                  Re: PEP 378: Format Specifier for Thousands Separator Terry Jan Reedy <tjreedy@udel.edu> - 2013-05-23 16:19 -0400
                  RE: PEP 378: Format Specifier for Thousands Separator Carlos Nepomuceno <carlosnepomuceno@outlook.com> - 2013-05-24 01:20 +0300
                  Re: PEP 378: Format Specifier for Thousands Separator Jerry Hill <malaclypse2@gmail.com> - 2013-05-23 21:17 -0400
                  RE: PEP 378: Format Specifier for Thousands Separator Carlos Nepomuceno <carlosnepomuceno@outlook.com> - 2013-05-24 04:41 +0300
              Re: PEP 378: Format Specifier for Thousands Separator Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-05-23 01:30 +0100
              RE: PEP 378: Format Specifier for Thousands Separator Carlos Nepomuceno <carlosnepomuceno@outlook.com> - 2013-05-23 03:44 +0300

#45686 — Re: PEP 378: Format Specifier for Thousands Separator

On 2013.05.21 14:26, Mark Lawrence wrote:
> On 21/05/2013 20:13, Skip Montanaro wrote:
>>> Thank you, but let me rephrase it. I'm already using str.format() but I'd like to use '%' (BINARY_MODULO) operator instead.
>>
>> That's unlikely to change.  If not deprecated already string
>> interpolation using the modulo operator has lost favor to the string
>> object's format method.
>>
> 
> Please stop perpetuating this myth, see 
> http://mail.python.org/pipermail/python-dev/2012-February/116789.html 
> and http://bugs.python.org/issue14123
> 
What myth? People should indeed be using .format(), but no one said % formatting was going away soon. Also, the suggested change to the docs
wasn't made and the issue is closed. The current docs do not say that % formatting isn't going to be deprecated, but it does mention its
caveats and suggests .format(). If you are trying to say that % formatting will never ever go away, then you are wrong. It is highly
unlikely to go away in a 3.x release, but /may/ get phased out in Python 4.0.
-- 
CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 9.1

[toc] | [next] | [standalone]

#45700

On Tue, 21 May 2013 14:53:54 -0500, Andrew Berg wrote:

> On 2013.05.21 14:26, Mark Lawrence wrote:

>> Please stop perpetuating this myth, see
>> http://mail.python.org/pipermail/python-dev/2012-February/116789.html
>> and http://bugs.python.org/issue14123
>> 
> What myth? 

The myth that % string formatting is deprecated. It is not deprecated.

> People should indeed be using .format(), 

If it is useful to them, and not too slow, or indeed if they merely want 
to. And if not, then not.

This is a good case where the original poster *should* use str.format, 
since it does exactly what he wants, and % does not. Python gives you 
many tools, and the wise man uses the right tool for the job. Sometimes 
that is % and sometimes it is str.format and sometimes it is 
string.Template.

That str.format looks like Java is irrelevant. Method call syntax is 
common in Python, and is not original to Java. Besides, Python looks like 
many languages: some parts look like Java, some parts look like C, some 
parts remind me of functional languages like Lisp and Haskell, and some 
parts look like Algol or Pascal.


> but no one said % formatting was going away soon.

True, but only for the definition "no one = all the people who insist 
that % is deprecated, or soon to be deprecated".


> Also, the suggested change to the docs
> wasn't made and the issue is closed. The current docs do not say that %
> formatting isn't going to be deprecated, but it does mention its caveats
> and suggests .format(). If you are trying to say that % formatting will
> never ever go away, then you are wrong. It is highly unlikely to go away
> in a 3.x release, but /may/ get phased out in Python 4.0.

What happens in Python 4000 is irrelevant. If somebody is trying to 
"future proof" their code for a version that *may never exist*, and if it 
does exist is likely to be six or eight years away from even starting the 
design phase, they are wasting their time. It is hard enough to track a 
moving target, it is impossible to track a target that isn't even a gleam 
in GvR's eye yet.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#45705

On 2013.05.21 21:59, Steven D'Aprano wrote:
> On Tue, 21 May 2013 14:53:54 -0500, Andrew Berg wrote:
> 
>> On 2013.05.21 14:26, Mark Lawrence wrote:
> 
>>> Please stop perpetuating this myth, see
>>> http://mail.python.org/pipermail/python-dev/2012-February/116789.html
>>> and http://bugs.python.org/issue14123
>>> 
>> What myth? 
> 
> The myth that % string formatting is deprecated. It is not deprecated.
Skip didn't say that it was deprecated.

>> but no one said % formatting was going away soon.
> 
> True, but only for the definition "no one = all the people who insist 
> that % is deprecated, or soon to be deprecated".
Perhaps I missed something, but who is insisting this?

> What happens in Python 4000 is irrelevant. If somebody is trying to 
> "future proof" their code for a version that *may never exist*, and if it 
> does exist is likely to be six or eight years away from even starting the 
> design phase, they are wasting their time. It is hard enough to track a 
> moving target, it is impossible to track a target that isn't even a gleam 
> in GvR's eye yet.
I think you misunderstand. I'm not suggesting that format() be used simply because % formatting could be deprecated at some unknown time
years from now; I was clarifying the status of % formatting.
-- 
CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 9.1

[toc] | [prev] | [next] | [standalone]

#45720

>>>> Please stop perpetuating this myth, see
>>>> http://mail.python.org/pipermail/python-dev/2012-February/116789.html
>>>> and http://bugs.python.org/issue14123
>>>>
>>> What myth?
>>
>> The myth that % string formatting is deprecated. It is not deprecated.
> Skip didn't say that it was deprecated.

I didn't mean to create a tempest in a teapot.  I was away from
comp.lang.python, python-bugs, and python-dev for a few years.  In
particular, I didn't ever see the aforementioned thread from Feb 2012.
 Had I known of that thread I would have worded the sentence which
shall not be repeated differently.

My apologies...

Skip

[toc] | [prev] | [next] | [standalone]

#45738

On Wed, 22 May 2013 05:45:12 -0500, Skip Montanaro wrote:

> I didn't mean to create a tempest in a teapot.  I was away from
> comp.lang.python, python-bugs, and python-dev for a few years.  In
> particular, I didn't ever see the aforementioned thread from Feb 2012.
>  Had I known of that thread I would have worded the sentence which
> shall not be repeated differently.
> 
> My apologies...

No problem, it's not about you specifically, it's just that some of us 
fans of % formatting can be a tad sensitive about it, especially since 
the idea that it has been deprecated (or soon will be deprecated, or one 
day will be deprecated, and therefore code using it is bad) is relatively 
widespread on the Internet.

Glad to have you back here!



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#45743

On 5/22/2013 10:58 AM, Steven D'Aprano wrote:
> On Wed, 22 May 2013 05:45:12 -0500, Skip Montanaro wrote:
>
>> I didn't mean to create a tempest in a teapot.  I was away from
>> comp.lang.python, python-bugs, and python-dev for a few years.  In
>> particular, I didn't ever see the aforementioned thread from Feb 2012.
>>   Had I known of that thread I would have worded the sentence which
>> shall not be repeated differently.
>>
>> My apologies...
> No problem, it's not about you specifically, it's just that some of us
> fans of % formatting can be a tad sensitive about it, especially since
> the idea that it has been deprecated (or soon will be deprecated, or one
> day will be deprecated, and therefore code using it is bad) is relatively
> widespread on the Internet.

Seems like maybe this should become a question in the Python FAQ.

--Ned.

>
> Glad to have you back here!
>
>
>

[toc] | [prev] | [next] | [standalone]

#45750

On May 22, 2:30 pm, Ned Batchelder <n...@nedbatchelder.com> wrote:
> On 5/22/2013 10:58 AM, Steven D'Aprano wrote:
>
> > On Wed, 22 May 2013 05:45:12 -0500, Skip Montanaro wrote:
>
> >> I didn't mean to create a tempest in a teapot.  I was away from
> >> comp.lang.python, python-bugs, and python-dev for a few years.  In
> >> particular, I didn't ever see the aforementioned thread from Feb 2012.
> >>   Had I known of that thread I would have worded the sentence which
> >> shall not be repeated differently.
>
> >> My apologies...
> > No problem, it's not about you specifically, it's just that some of us
> > fans of % formatting can be a tad sensitive about it, especially since
> > the idea that it has been deprecated (or soon will be deprecated, or one
> > day will be deprecated, and therefore code using it is bad) is relatively
> > widespread on the Internet.
>
> Seems like maybe this should become a question in the Python FAQ.
>
> --Ned.
>
>
>
>
>
>
>
>
>
> > Glad to have you back here!

Maybe a cformat(formatstring, variables)  function should be created
in the string module so people who prefer that can use it. I don't
mind the C formatting syntax but I don't like the fact that the %
operator does something totally different when the first variable is
an integer and the fact that it misbehaves if the second variable is a
tuple.

[toc] | [prev] | [next] | [standalone]

#45754

----------------------------------------
> Date: Wed, 22 May 2013 13:26:23 -0700
> Subject: Re: PEP 378: Format Specifier for Thousands Separator
> From: pruebauno@latinmail.com
> To: python-list@python.org
[...]
>
> Maybe a cformat(formatstring, variables) function should be created
> in the string module so people who prefer that can use it. I don't
> mind the C formatting syntax but I don't like the fact that the %
> operator does something totally different when the first variable is
> an integer and the fact that it misbehaves if the second variable is a
> tuple.
> --
> http://mail.python.org/mailman/listinfo/python-list

I still don't understand why % benefits from literals optimization ("'%d'%12345") while '{:d}'.format(12345) doesn't.

What "totally different" you talking about? Please give me an example. 		 	   		  

[toc] | [prev] | [next] | [standalone]

#45809

On May 22, 6:31 pm, Carlos Nepomuceno <carlosnepomuc...@outlook.com>
wrote:
> ----------------------------------------
>
> > Date: Wed, 22 May 2013 13:26:23 -0700
> > Subject: Re: PEP 378: Format Specifier for Thousands Separator
> > From: prueba...@latinmail.com
> > To: python-l...@python.org
> [...]
>
> > Maybe a cformat(formatstring, variables) function should be created
> > in the string module so people who prefer that can use it. I don't
> > mind the C formatting syntax but I don't like the fact that the %
> > operator does something totally different when the first variable is
> > an integer and the fact that it misbehaves if the second variable is a
> > tuple.
> > --
> >http://mail.python.org/mailman/listinfo/python-list
>
> I still don't understand why % benefits from literals optimization ("'%d'%12345") while '{:d}'.format(12345) doesn't.
>
> What "totally different" you talking about? Please give me an example.

>>> def eggs(spam, ham): return spam % ham

>>> def milk(beef, steak): return beef.format(steak)

>>> a='%s'
>>> c=9
>>> d=4
>>> e=[1,2]
>>> f=(3,5)
>>> d='{}'

>>> eggs(a,4)
'4'
>>> eggs(c,4)
1
>>> eggs(a,e)
'[1, 2]'
>>> eggs(a,f)
Traceback (most recent call last):
  File "<pyshell#29>", line 1, in <module>
    eggs(a,f)
  File "<pyshell#1>", line 1, in eggs
    def eggs(spam, ham): return spam % ham
TypeError: not all arguments converted during string formatting
>>> '%s'%(5%3)
'2'

>>> milk(d,4)
'4'
>>> milk(c,4)
Traceback (most recent call last):
  File "<pyshell#53>", line 1, in <module>
    milk(c,4)
  File "<pyshell#49>", line 1, in milk
    def milk(beef, steak): return beef.format(steak)
AttributeError: 'int' object has no attribute 'format'
>>> milk(d,e)
'[1, 2]'
>>> milk(d,f)
'(3, 5)'
>>> '{}'.format(5%3)
'2'

[toc] | [prev] | [next] | [standalone]

#45813

----------------------------------------
> Date: Thu, 23 May 2013 06:44:05 -0700
> Subject: Re: PEP 378: Format Specifier for Thousands Separator
> From: pruebauno@latinmail.com
> To: python-list@python.org
[...]
>>>> eggs(a,f)
> Traceback (most recent call last):
> File "<pyshell#29>", line 1, in <module>
> eggs(a,f)
> File "<pyshell#1>", line 1, in eggs
> def eggs(spam, ham): return spam % ham
> TypeError: not all arguments converted during string formatting
>>>> '%s'%(5%3)
> '2'

So % doesn't handle tuples! Why's that? Is it intentional (by design)? 		 	   		  

[toc] | [prev] | [next] | [standalone]

#45832

On 05/23/2013 11:26 AM, Carlos Nepomuceno wrote:
> ----------------------------------------
>> Date: Thu, 23 May 2013 06:44:05 -0700
>> Subject: Re: PEP 378: Format Specifier for Thousands Separator
>> From: pruebauno@latinmail.com
>> To: python-list@python.org
> [...]

You left out the part where a and f are initialized:


 >>> a='%s'
 >>> f=(3,5)


>>>>> eggs(a,f)
>> Traceback (most recent call last):
>> File "<pyshell#29>", line 1, in <module>
>> eggs(a,f)
>> File "<pyshell#1>", line 1, in eggs
>> def eggs(spam, ham): return spam % ham
>> TypeError: not all arguments converted during string formatting
>>>>> '%s'%(5%3)
>> '2'
>
> So % doesn't handle tuples! Why's that? Is it intentional (by design)? 		 	   		
>

It's a conflict in the design.  A tuple is used to supply multiple 
arguments to the % operator.  So if you want to have a tuple as the 
first argument, you need to enclose it in another tuple.

try the following:

print a % (f,)

The trouble is, it doesn't generalize very readily, so it's difficult to 
use in a function like eggs()

-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#45889

On May 23, 2:42 pm, Dave Angel <da...@davea.name> wrote:
> On 05/23/2013 11:26 AM, Carlos Nepomuceno wrote:
>
> > ----------------------------------------
> >> Date: Thu, 23 May 2013 06:44:05 -0700
> >> Subject: Re: PEP 378: Format Specifier for Thousands Separator
> >> From: prueba...@latinmail.com
> >> To: python-l...@python.org
> > [...]
>
> You left out the part where a and f are initialized:
>
>  >>> a='%s'
>  >>> f=(3,5)
>
> >>>>> eggs(a,f)
> >> Traceback (most recent call last):
> >> File "<pyshell#29>", line 1, in <module>
> >> eggs(a,f)
> >> File "<pyshell#1>", line 1, in eggs
> >> def eggs(spam, ham): return spam % ham
> >> TypeError: not all arguments converted during string formatting
> >>>>> '%s'%(5%3)
> >> '2'
>
> > So % doesn't handle tuples! Why's that? Is it intentional (by design)?
>
> It's a conflict in the design.  A tuple is used to supply multiple
> arguments to the % operator.  So if you want to have a tuple as the
> first argument, you need to enclose it in another tuple.
>
> try the following:
>
> print a % (f,)
>
> The trouble is, it doesn't generalize very readily, so it's difficult to
> use in a function like eggs()
>
> --
> DaveA

It's all there, it's just that quoting ate it. Let's try this again:

>>> def eggs(spam, ham): return spam % ham
>>> def milk(beef, steak): return beef.format(steak)
>>> a='%s'
>>> c=9
>>> d=4
>>> e=[1,2]
>>> f=(3,5)
>>> d='{}'
>>> eggs(a,4)
'4'
>>> eggs(c,4)
1
>>> eggs(a,e)
'[1, 2]'
>>> eggs(a,f)

Traceback (most recent call last):
  File "<pyshell#29>", line 1, in <module>
    eggs(a,f)
  File "<pyshell#1>", line 1, in eggs
    def eggs(spam, ham): return spam % ham
TypeError: not all arguments converted during string formatting
>>> '%s'%(5%3)
'2'

>>> milk(d,4)
'4'
>>> milk(c,4)

Traceback (most recent call last):
  File "<pyshell#53>", line 1, in <module>
    milk(c,4)
  File "<pyshell#49>", line 1, in milk
    def milk(beef, steak): return beef.format(steak)
AttributeError: 'int' object has no attribute 'format'
>>> milk(d,e)
'[1, 2]'
>>> milk(d,f)
'(3, 5)'
>>> '{}'.format(5%3)
'2'

The three issues represented:
1. Functions in which both values of the operator are parameters might
not return a string but an integer instead. It is not always
immediately obvious when reading such functions if modulus or
formatting is intended.
2. Function doesn't handle tuple properly unless carefully written
3. Too much % noise because % is used for 3 things: the special
placeholder character inside format strings, the format operator and
the modulus operator.

[toc] | [prev] | [next] | [standalone]

#45841

On 5/23/2013 2:42 PM, Dave Angel wrote:
> On 05/23/2013 11:26 AM, Carlos Nepomuceno wrote:

>
>>>>>> eggs(a,f)
>>> Traceback (most recent call last):
>>> File "<pyshell#29>", line 1, in <module>
>>> eggs(a,f)
>>> File "<pyshell#1>", line 1, in eggs
>>> def eggs(spam, ham): return spam % ham
>>> TypeError: not all arguments converted during string formatting
>>>>>> '%s'%(5%3)
>>> '2'
>>
>> So % doesn't handle tuples! Why's that? Is it intentional (by design)?
>>
>
> It's a conflict in the design.  A tuple is used to supply multiple
> arguments to the % operator.  So if you want to have a tuple as the
> first argument, you need to enclose it in another tuple.

The problem is that interpolating 1 to many items into a string is *not* 
a binary operation. The needed hack to pretend that it is, using a tuple 
to represent multiple items rather than just itself, was one of the 
reasons for making string formatting a honest function, where multiple 
items to be formatted are passed as multiple arguments.

[toc] | [prev] | [next] | [standalone]

#45848

----------------------------------------
> To: python-list@python.org
> From: tjreedy@udel.edu
[...]
>> It's a conflict in the design. A tuple is used to supply multiple
>> arguments to the % operator. So if you want to have a tuple as the
>> first argument, you need to enclose it in another tuple.
>
> The problem is that interpolating 1 to many items into a string is *not*
> a binary operation. The needed hack to pretend that it is, using a tuple
> to represent multiple items rather than just itself, was one of the
> reasons for making string formatting a honest function, where multiple
> items to be formatted are passed as multiple arguments.

Thanks so much guys! Now I understand why some people hate %-formatting!

I don't think that's a problem because there's no format specifier for tuples in the %-formatting definition[1].
So it's up to the user to make the necessary conversion.

I still love the %-formatting style!

Can str.format() do the following?

f = '%d %d %d'
v = '1,2,3'
print f % eval(v)

If yes, how?


[1] http://docs.python.org/2/library/stdtypes.html#string-formatting 		 	   		  

[toc] | [prev] | [next] | [standalone]

#45858

[Multipart message — attachments visible in raw view] — view raw

On Thu, May 23, 2013 at 6:20 PM, Carlos Nepomuceno <
carlosnepomuceno@outlook.com> wrote:

> Can str.format() do the following?
>
> f = '%d %d %d'
> v = '1,2,3'
> print f % eval(v)
>

​Sure:

Python 3.2.2 (default, Sep  4 2011, 09:51:08) [MSC v.1500 32 bit (Intel)]
on win32
>>> f = "{} {} {}"
>>> v = "1,2,3"
>>> print(f.format(*eval(v)))
1 2 3
>>>

The * unpacks the tuple returned from eval(), so that you get 3 separate
parameters passed to format(), instead of the single tuple.​

--
​
Jerry​

[toc] | [prev] | [next] | [standalone]

#45860

Thank you! Hail Eris!!! :)

________________________________
> Date: Thu, 23 May 2013 21:17:54 -0400 
> Subject: Re: PEP 378: Format Specifier for Thousands Separator 
> From: malaclypse2@gmail.com 
> To: carlosnepomuceno@outlook.com 
> CC: python-list@python.org 
>  
> On Thu, May 23, 2013 at 6:20 PM, Carlos Nepomuceno  
> <carlosnepomuceno@outlook.com<mailto:carlosnepomuceno@outlook.com>>  
> wrote: 
> Can str.format() do the following? 
>  
> f = '%d %d %d' 
> v = '1,2,3' 
> print f % eval(v) 
>  
> ​Sure: 
>  
> Python 3.2.2 (default, Sep  4 2011, 09:51:08) [MSC v.1500 32 bit  
> (Intel)] on win32 
> >>> f = "{} {} {}" 
> >>> v = "1,2,3" 
> >>> print(f.format(*eval(v))) 
> 1 2 3 
> >>> 
>  
> The * unpacks the tuple returned from eval(), so that you get 3  
> separate parameters passed to format(), instead of the single tuple.​ 
>  
> -- 
> ​ 
> Jerry​ 
> 		 	   		  

[toc] | [prev] | [next] | [standalone]

#45762

On 22 May 2013 23:31, Carlos Nepomuceno <carlosnepomuceno@outlook.com> wrote:
>
> I still don't understand why % benefits from literals optimization ("'%d'%12345") while '{:d}'.format(12345) doesn't.

There's no reason why that optimisation can't happen in principle.
However no one has written a patch for it. Why don't you look into
what it would take to make it happen?


Oscar

[toc] | [prev] | [next] | [standalone]

#45765

----------------------------------------
> From: oscar.j.benjamin@gmail.com
> Date: Thu, 23 May 2013 01:30:53 +0100
> Subject: Re: PEP 378: Format Specifier for Thousands Separator
> To: carlosnepomuceno@outlook.com
> CC: pruebauno@latinmail.com; python-list@python.org
>
> On 22 May 2013 23:31, Carlos Nepomuceno <carlosnepomuceno@outlook.com> wrote:
>>
>> I still don't understand why % benefits from literals optimization ("'%d'%12345") while '{:d}'.format(12345) doesn't.
>
> There's no reason why that optimisation can't happen in principle.
> However no one has written a patch for it. Why don't you look into
> what it would take to make it happen?
>
>
> Oscar

Maybe I'll look into that later, but I couldn't even find how the hell they made _Py_InsertThousandsGrouping() been called.

That's what I got when analysing % formating:

Thousands separator format specifier for str.__mod__()
======================================================

@Objects/stringobject.c: implements formatint() for '%' processing
-Looking for code used in str.format()

@Objects/stringlib/formatter.h: implements str.format()
-It uses STRINGLIB_GROUPING() to do the job.

@Objects/stringlib/stringdefs.h: #define STRINGLIB_GROUPING       _PyString_InsertThousandsGrouping
@Objects/stringlib/unicodedefs.h: #define STRINGLIB_GROUPING       _PyUnicode_InsertThousandsGrouping
@Objects/stringobject.c: #define _Py_InsertThousandsGrouping _PyString_InsertThousandsGrouping
@Objects/stringobject.h: declares _PyString_InsertThousandsGrouping()
@???: ??? _PyString_InsertThousandsGrouping ??? _Py_InsertThousandsGrouping
@Objects/stringlib/localeutil.h: implements _Py_InsertThousandsGrouping()


Let me explain what that means. I found no relating declarations/definitions that turn _PyString_InsertThousandsGrouping into _Py_InsertThousandsGrouping.

So, I don't even know how that source code compiles without error.

:/ really strange...


Not to mention the lots of code inside header definition files! Weird!!!! 		 	   		  

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web