Re: Rough draft: Proposed format specifier for a thousands separator

Raymond Hettinger wrote in news:e35271b9-7623-4845-bcb9-d8c33971f...@w24g2000prd.googlegroups.c om: > If anyone here is interested, here is a proposal I posted on the > python-ideas list. > > The idea is to make numbering formatting a little easier with the > new format() builtin > in Py2.6 and

Re: Rough draft: Proposed format specifier for a thousands separator

On Tue, 17 Mar 2009 02:41:23 -, MRAB wrote: Rhodri James wrote: On Tue, 17 Mar 2009 01:47:32 -, MRAB wrote: I'm not against putting a comma in the format to indicate that grouping should be used just as a dot indicates that a decimal point should be used. The locale would say wh

Re: Rough draft: Proposed format specifier for a thousands separator

Rhodri James wrote: On Tue, 17 Mar 2009 01:47:32 -, MRAB wrote: I'm not against putting a comma in the format to indicate that grouping should be used just as a dot indicates that a decimal point should be used. The locale would say what characters would be used for them. I would prefer

Re: Rough draft: Proposed format specifier for a thousands separator

On Tue, 17 Mar 2009 01:47:32 -, MRAB wrote: I'm not against putting a comma in the format to indicate that grouping should be used just as a dot indicates that a decimal point should be used. The locale would say what characters would be used for them. I would prefer the format to have a

Re: Rough draft: Proposed format specifier for a thousands separator

Rhodri James wrote: On Mon, 16 Mar 2009 23:04:58 -, MRAB wrote: It should probably(?) be: financial = Locale(group_sep=",", grouping=[3]) print("my number is {0:10n:fin}".format(1234567, fin=financial)) The format "10n" says whether to use separators or a decimal point; the lo

Re: Rough draft: Proposed format specifier for a thousands separator

On Mon, 16 Mar 2009 23:04:58 -, MRAB wrote: It should probably(?) be: financial = Locale(group_sep=",", grouping=[3]) print("my number is {0:10n:fin}".format(1234567, fin=financial)) The format "10n" says whether to use separators or a decimal point; the locale "fin" says what

Re: Rough draft: Proposed format specifier for a thousands separator

Rhodri James wrote: On Mon, 16 Mar 2009 02:36:43 -, MRAB wrote: The field name can be an integer or an identifier, so the locale could be too, provided that you know where to look it up! financial = Locale(group_sep=",", grouping=[3]) print("my number is {0:10n:{fin}}".format(1

Re: Rough draft: Proposed format specifier for a thousands separator

On Mon, 16 Mar 2009 02:36:43 -, MRAB wrote: The field name can be an integer or an identifier, so the locale could be too, provided that you know where to look it up! financial = Locale(group_sep=",", grouping=[3]) print("my number is {0:10n:{fin}}".format(1234567, fin=financia

Re: Rough draft: Proposed format specifier for a thousands separator

Rhodri James wrote: On Sun, 15 Mar 2009 19:00:43 -, MRAB wrote: Rhodri James wrote: [snip] Frankly, I'd much rather fix the locale system and extend the format syntax to override the default locale. Perhaps something like financial = Locale(group_sep=",", grouping=[3]) print("my nu

Re: Rough draft: Proposed format specifier for a thousands separator

On Sun, 15 Mar 2009 19:00:43 -, MRAB wrote: Rhodri James wrote: [snip] Frankly, I'd much rather fix the locale system and extend the format syntax to override the default locale. Perhaps something like financial = Locale(group_sep=",", grouping=[3]) print("my number is {0:10n:finan

Re: Rough draft: Proposed format specifier for a thousands separator

2009/3/14 Hendrik van Rooyen : > No account seems to be taken of the fact that the locale approach > is a global one that forces uniformity on everything done on a PC > or by a user. Not so. Under .NET, for instance, the global settings will give you a default CultureInfo class, but you can creat

Re: Rough draft: Proposed format specifier for a thousands separator

Rhodri James wrote: [snip] Frankly, I'd much rather fix the locale system and extend the format syntax to override the default locale. Perhaps something like financial = Locale(group_sep=",", grouping=[3]) print("my number is {0:10n:financial}".format(1234567)) It's hard to think of a way

Re: Rough draft: Proposed format specifier for a thousands separator

On Sat, 14 Mar 2009 08:20:21 -, Hendrik van Rooyen wrote: "Tim Rowe" wrote: 8< - . If "Finance users and non-professional programmers find the locale approach to be frustrating, arcane and non-obvious" then by all

Re: Rough draft: Proposed format specifier for a thousands separator

Raymond Hettinger wrote: > No doubt that you're skeptical of anything you didn't > already know ;-) I'm a CPA, was a 15 year division controller > for a Fortune 500 company, and an auditor for an international > accounting firm. Believe me when I say it is the norm in finance. > Besides, it seem

Re: Rough draft: Proposed format specifier for a thousands separator

"Paul Rubin" wrote: > Paul Rubin writes: > >'%.3K' % 1234567 = 1.235K # K = 1000 > >'%.:3Ki' % 1234567 = 1.206K # K = 1024 > > I meant 1.235M and 1.177M, of course. I went "tilt" like a slot machine long before I noticed.

Re: Rough draft: Proposed format specifier for a thousands separator

"Tim Rowe" wrote: 8< - > . If "Finance users and non-professional > programmers find the locale approach to be frustrating, arcane and > non-obvious" then by all means propose a way of making it simpler and > clearer, but no

Re: Rough draft: Proposed format specifier for a thousands separator

"John Nagle" wrote: > Yes. In COBOL, one writes > > PICTURE $999,999,999.99 > > which is is way ahead of most of the later approaches. That was fixed width. For zero suppression: PIC ,$$$,$99.99 This will format 1000 as $1,000.00 For fixed width zero suppression: PIC $ZZZ,ZZZ,Z9

Re: Rough draft: Proposed format specifier for a thousands separator

[Lie Ryan] > My proposition is: make the format specifier a simpler API to locale > aware You do know that we already have one, right? That's what the existing "n" specifier does. Raymond -- http://mail.python.org/mailman/listinfo/python-list

Re: Rough draft: Proposed format specifier for a thousands separator

Raymond Hettinger wrote: [Lie Ryan] > In the finance world, output with commas is the norm. I can't cite any source, but I am skeptical with that. No doubt that you're skeptical of anything you didn't already know ;-) I'm a CPA, was a 15 year division controller for a Fortune 500 compan

Re: Rough draft: Proposed format specifier for a thousands separator

Raymond Hettinger wrote: If anyone here is interested, here is a proposal I posted on the python-ideas list. The idea is to make numbering formatting a little easier with the new format() builtin in Py2.6 and Py3.0: http://docs.python.org/library/string.html#formatspec ---

Re: Rough draft: Proposed format specifier for a thousands separator

[Lie Ryan] >  >     In the finance world, output with commas is the norm. > > I can't cite any source, but I am skeptical with that. No doubt that you're skeptical of anything you didn't already know ;-) I'm a CPA, was a 15 year division controller for a Fortune 500 company, and an auditor for an

Re: Rough draft: Proposed format specifier for a thousands separator

Raymond Hettinger wrote: Motivation: Provide a simple, non-locale aware way to format a number with a thousands separator. Adding thousands separators is one of the simplest ways to improve the professional appearance and readability of output exposed to end users. In

Re: Rough draft: Proposed format specifier for a thousands separator

Paul Rubin writes: >'%.3K' % 1234567 = 1.235K # K = 1000 >'%.:3Ki' % 1234567 = 1.206K # K = 1024 I meant 1.235M and 1.177M, of course. -- http://mail.python.org/mailman/listinfo/python-list

Re: Rough draft: Proposed format specifier for a thousands separator

Tim Rowe writes: > And if it's mostly for programmers' eyes, why does the motivation > state that "Adding thousands separators is one of the simplest ways to > improve the professional appearance and readability of output exposed > to end users"? It occurs to me, at least for quantities of data,

Re: Rough draft: Proposed format specifier for a thousands separator

Raymond Hettinger wrote: Todays updates to: http://www.python.org/dev/peps/pep-0378/ * Detail issues with the locale module. * Summarize commentary to date. -- Opposition to formatting strings in general (preferring a convenience function or PICTURE clause) -- Opposition to any non-

Re: Rough draft: Proposed format specifier for a thousands separator

Todays updates to: http://www.python.org/dev/peps/pep-0378/ * Detail issues with the locale module. * Summarize commentary to date. -- Opposition to formatting strings in general (preferring a convenience function or PICTURE clause) -- Opposition to any non-locale aware approach * Add

Re: Rough draft: Proposed format specifier for a thousands separator

Lie Ryan wrote: Hendrik van Rooyen wrote: "Ulrich Eckhardt" wrote: Look back in history, and see how COBOL did it with the PICTURE - dead easy and easily understandable. Compared to that, even the C printf stuff and python's % are incomprehensible. - Hendrik Yes. In COBOL, one writes

Re: Rough draft: Proposed format specifier for a thousands separator

> > The separators can be any one of COMMA, > > SPACE, DOT, UNDERSCORE, or NON-BREAKING-SPACE. > > What if I want other separators? format(n, ',d').replace(",", yoursep) > How about this idea: make the format has "long" format, which is a bit > more verbose, flexible, and unambiguous, and the cu

Re: Rough draft: Proposed format specifier for a thousands separator

Raymond Hettinger wrote: [andrew cooke] would it break anything to also allow format(1234567, 'd') # what we have now '1234567' format(1234567, '.d') # proposed new option '1.234.567' format(1234.5, ',2f') # proposed new option '1234,50' format(1234.5, '.,2f') # pr

Re: Rough draft: Proposed format specifier for a thousands separator

2009/3/13 : > I think this proposal is more for debugging big numbers and meant mostly > for programmers' eyes. We are already using the dot instead of comma > decimal separator in our programming languages that one more > Americanism won't kill us. If it were for the programmers' eyes then it wo

Re: Rough draft: Proposed format specifier for a thousands separator

On Mar 13, 7:06 am, Tim Rowe wrote: > 2009/3/12 Raymond Hettinger : > > > If anyone here is interested, here is a proposal I posted on the > > python-ideas list. > > > The idea is to make numbering formatting a little easier with the new > > format() builtin > > in Py2.6 and Py3.0:  http://docs.py

Re: Rough draft: Proposed format specifier for a thousands separator

On Freitag, 13. März 2009, Raymond Hettinger wrote: > [Paul Rubin] > > What if you want to change the separator? Europeans usually > > use periods instead of commas: one thousand = 1.000. > > That is supported also. do you support just a fixed set of separators or anything? how about this: (Swi

Re: Rough draft: Proposed format specifier for a thousands separator

[Paul Rubin] > What if you want to change the separator?  Europeans usually > use periods instead of commas: one thousand = 1.000. That is supported also. -- http://mail.python.org/mailman/listinfo/python-list

Re: Rough draft: Proposed format specifier for a thousands separator

[andrew cooke] > would it break anything to also allow > > >>> format(1234567, 'd')       # what we have now >  '1234567' > >>> format(1234567, '.d')      # proposed new option >  '1.234.567' > >>> format(1234.5, ',2f')      # proposed new option >  '1234,50' > >>> format(1234.5, '.,2f')     # prop

Re: Rough draft: Proposed format specifier for a thousands separator

Raymond Hettinger writes: > The proposal is roughly: > If you want commas in the output, > put a comma in the format string. > It's not rocket science. What if you want to change the separator? Europeans usually use periods instead of commas: one thousand = 1.000. -- http://mail.python.org/m

Re: Rough draft: Proposed format specifier for a thousands separator

Raymond Hettinger wrote: > [Lie Ryan] >> A hyphotetical code using conv function and the microlanguage could look >> like this: >> >>  >>> num = 213210.3242 >>  >>> fmt = create_format(sep='-', decsep='@') >>  >>> print fmt >> 50|\/|3_v3ry_R34D4|3L3_C0D3 >>  >>> '{0!{1}}'.format(num, fmt) >> '213-.

Re: Rough draft: Proposed format specifier for a thousands separator

2009/3/12 Raymond Hettinger : > If anyone here is interested, here is a proposal I posted on the > python-ideas list. > > The idea is to make numbering formatting a little easier with the new > format() builtin > in Py2.6 and Py3.0:  http://docs.python.org/library/string.html#formatspec As far as

Re: Rough draft: Proposed format specifier for a thousands separator

[Lie Ryan] > A hyphotetical code using conv function and the microlanguage could look > like this: > >  >>> num = 213210.3242 >  >>> fmt = create_format(sep='-', decsep='@') >  >>> print fmt > 50|\/|3_v3ry_R34D4|3L3_C0D3 >  >>> '{0!{1}}'.format(num, fmt) > '213-...@3242' LOL, it's like APL all ove

Re: Rough draft: Proposed format specifier for a thousands separator

Hendrik van Rooyen wrote: "Ulrich Eckhardt" wrote: IOW, why not explicitly say what you want using keyword arguments with defaults instead of inventing an IMHO cryptic, read-only mini-language? Seriously, the problem I see with this proposal is that its aim to be as short as possible actually

Re: Rough draft: Proposed format specifier for a thousands separator

Raymond Hettinger wrote: <... a generally interesting PEP...> Missing from this PEP: output below the decimal point. show results for something like: format(12345.54321, "15,.5f") --> ' 12,345.543,21' Explain the interaction on sizes and lengths (which numbers are digits, which are length [

Re: Rough draft: Proposed format specifier for a thousands separator

Raymond Hettinger writes: > I found the Common Lisp spec for this and added it to the PEP. Ah, cool, I simultaneously looked for it and posted about it. -- http://mail.python.org/mailman/listinfo/python-list

Re: Rough draft: Proposed format specifier for a thousands separator

Raymond Hettinger writes: > In my quick research, it looks like many languages offer > nothing more than the usual C style % formatting and defer > the rest for a local aware module. Hendrik van Rooyen's mention of Cobol's "picture" (aka PIC) specifications might be added to the list. Cautionary

Re: Rough draft: Proposed format specifier for a thousands separator

[Paul Rubin] > I think Common Lisp has a feature for formatting thousands. I found the Common Lisp spec for this and added it to the PEP. Raymond -- http://mail.python.org/mailman/listinfo/python-list

Re: Rough draft: Proposed format specifier for a thousands separator

[Paul Rubin] > It would be nice if the PEP included a comparison between the proposed > scheme and how it is done in other programs and languages. Good idea. I'm hoping that people will post those here. In my quick research, it looks like many languages offer nothing more than the usual C style %

Re: Rough draft: Proposed format specifier for a thousands separator

Raymond Hettinger writes: > FWIW, posted a cleaned-up version of the proposal at > http://www.python.org/dev/peps/pep-0378/ It would be nice if the PEP included a comparison between the proposed scheme and how it is done in other programs and languages. For example, I think Common Lisp has a f

Re: Rough draft: Proposed format specifier for a thousands separator

On Mar 12, 7:51 am, prueba...@latinmail.com wrote: > On Mar 12, 3:30 am, Raymond Hettinger wrote: > > > > > If anyone here is interested, here is a proposal I posted on the > > python-ideas list. > > > The idea is to make numbering formatting a little easier with the new > > format() builtin > > i

Re: Rough draft: Proposed format specifier for a thousands separator

On Mar 12, 3:30 am, Raymond Hettinger wrote: > If anyone here is interested, here is a proposal I posted on the > python-ideas list. > > The idea is to make numbering formatting a little easier with the new > format() builtin > in Py2.6 and Py3.0:  http://docs.python.org/library/string.html#format

Re: Rough draft: Proposed format specifier for a thousands separator

On Mar 12, 9:56 pm, Raymond Hettinger wrote: > [Ulrich Eckhardt] > > > IOW, why not explicitly say what you want using keyword arguments with > > defaults instead of inventing an IMHO cryptic, read-only mini-language? > > That makes sense to me but I don't think that's the way the format() > built

Re: Rough draft: Proposed format specifier for a thousands separator

"Ulrich Eckhardt" wrote: >IOW, why not explicitly say what you want using keyword arguments with >defaults instead of inventing an IMHO cryptic, read-only mini-language? >Seriously, the problem I see with this proposal is that its aim to be as >short as possible actually makes the resulting forma

Re: Rough draft: Proposed format specifier for a thousands separator

Raymond Hettinger wrote: [snip] Proposal I (from Nick Coghlan): --- A comma will be added to the format() specifier mini-language: [[fill]align][sign][#][0][minimumwidth][,][.precision][type] The ',' option indicates that commas should be included in the output as a

Re: Rough draft: Proposed format specifier for a thousands separator

[Ulrich Eckhardt] > IOW, why not explicitly say what you want using keyword arguments with > defaults instead of inventing an IMHO cryptic, read-only mini-language? That makes sense to me but I don't think that's the way the format() builtin was implemented (see PEP 3101 which was implemented Py2.

Re: Rough draft: Proposed format specifier for a thousands separator

Raymond Hettinger wrote: >> The idea is to make numbering formatting a little easier with >> the new format() builtin: >> http://docs.python.org/library/string.html#formatspec [...] > Scanning the web, I've found that thousands separators are > usually one of COMMA, PERIOD, SPACE, or UNDERSCORE. T

Re: Rough draft: Proposed format specifier for a thousands separator

> If anyone here is interested, here is a proposal I posted on the > python-ideas list. > > The idea is to make numbering formatting a little easier with > the new format() builtin: > http://docs.python.org/library/string.html#formatspec Here's a re-post (hopefully without the line wrapping proble