forked from python/peps
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathpep-0378.txt
251 lines (178 loc) · 9 KB
/
pep-0378.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
PEP: 378
Title: Format Specifier for Thousands Separator
Version: $Revision$
Last-Modified: $Date$
Author: Raymond Hettinger <[email protected]>
Status: Final
Type: Standards Track
Content-Type: text/x-rst
Created: 12-Mar-2009
Python-Version: 2.7, 3.1
Post-History: 12-Mar-2009
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
humanize a program's output, improving its professional appearance
and readability.
In the finance world, output with thousands separators is the norm.
Finance users and non-professional programmers find the locale
approach to be frustrating, arcane and non-obvious.
The locale module presents two other challenges. First, it is
a global setting and not suitable for multi-threaded apps that
need to serve-up requests in multiple locales. Second, the
name of a relevant locale (such as "de_DE") can vary from
platform to platform or may not be defined at all. The docs
for the locale module describe these and `many other challenges`_
in detail.
.. _`many other challenges`: https://docs.python.org/2.6/library/locale.html#background-details-hints-tips-and-caveats
It is not the goal to replace the locale module, to perform
internationalization tasks, or accommodate every possible
convention. Such tasks are better suited to robust tools like
`Babel`_. Instead, the goal is to make a common, everyday
task easier for many users.
.. _`Babel`: http://babel.edgewall.org/
Main Proposal (from Nick Coghlan, originally called Proposal I)
===============================================================
A comma will be added to the format() specifier mini-language::
[[fill]align][sign][#][0][width][,][.precision][type]
The ',' option indicates that commas should be included in the
output as a thousands separator. As with locales which do not
use a period as the decimal point, locales which use a
different convention for digit separation will need to use the
locale module to obtain appropriate formatting.
The proposal works well with floats, ints, and decimals.
It also allows easy substitution for other separators.
For example::
format(n, "6,d").replace(",", "_")
This technique is completely general but it is awkward in the
one case where the commas and periods need to be swapped::
format(n, "6,f").replace(",", "X").replace(".", ",").replace("X", ".")
The *width* argument means the total length including the commas
and decimal point::
format(1234, "08,d") --> '0001,234'
format(1234.5, "08,.1f") --> '01,234.5'
The ',' option is defined as shown above for types 'd', 'e',
'f', 'g', 'E', 'G', '%', 'F' and ''. To allow future extensions, it is
undefined for other types: binary, octal, hex, character,
etc.
This proposal has the virtue of being simpler than the alternative
proposal but is much less flexible and meets the needs of fewer
users right out of the box. It is expected that some other
solution will arise for specifying alternative separators.
Current Version of the Mini-Language
====================================
* `Python 2.6 docs`_
.. _Python 2.6 docs: https://docs.python.org/2.6/library/string.html#formatstrings
* :pep:`3101` Advanced String Formatting
Research into what Other Languages Do
=====================================
Scanning the web, I've found that thousands separators are
usually one of COMMA, DOT, SPACE, APOSTROPHE or UNDERSCORE.
`C-Sharp`_ provides both styles (picture formatting and type specifiers).
The type specifier approach is locale aware. The picture formatting only
offers a COMMA as a thousands separator::
String.Format("{0:n}", 12400) ==> "12,400"
String.Format("{0:0,0}", 12400) ==> "12,400"
.. _`C-Sharp`: http://blog.stevex.net/index.php/string-formatting-in-csharp/
`Common Lisp`_ uses a COLON before the ``~D`` decimal type specifier to
emit a COMMA as a thousands separator. The general form of ``~D`` is
``~mincol,padchar,commachar,commaintervalD``. The *padchar* defaults
to SPACE. The *commachar* defaults to COMMA. The *commainterval*
defaults to three.
::
(format nil "~:D" 229345007) => "229,345,007"
.. _`Common Lisp`: http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node200.html
* The `ADA language`_ allows UNDERSCORES in its numeric literals.
.. _`ADA language`: http://archive.adaic.com/standards/83lrm/html/lrm-02-04.html
Visual Basic and its brethren (like `MS Excel`_) use a completely
different style and have ultra-flexible custom format
specifiers like::
"_($* #,##0_)".
.. _`MS Excel`: http://www.brainbell.com/tutorials/ms-office/excel/Create_Custom_Number_Formats.htm
`COBOL`_ uses picture clauses like::
PICTURE $***,**9.99CR
.. _`COBOL`: http://en.wikipedia.org/wiki/Cobol#Syntactic_features
Java offers a `Decimal.Format Class`_ that uses picture patterns (one
for positive numbers and an optional one for negatives) such as:
``"#,##0.00;(#,##0.00)"``. It allows arbitrary groupings including
hundreds and ten-thousands and uneven groupings. The special pattern
characters are non-localized (using a DOT for a decimal separator and
a COMMA for a grouping separator). The user can supply an alternate
set of symbols using the formatter's *DecimalFormatSymbols* object.
.. _`Decimal.Format Class`: http://java.sun.com/javase/6/docs/api/java/text/DecimalFormat.html
Alternative Proposal (from Eric Smith, originally called Proposal II)
=====================================================================
Make both the thousands separator and decimal separator user
specifiable but not locale aware. For simplicity, limit the
choices to a COMMA, DOT, SPACE, APOSTROPHE or UNDERSCORE.
The SPACE can be either U+0020 or U+00A0.
Whenever a separator is followed by a precision, it is a
decimal separator and an optional separator preceding it is a
thousands separator. When the precision is absent, a lone
specifier means a thousands separator::
[[fill]align][sign][#][0][width][tsep][dsep precision][type]
Examples::
format(1234, "8.1f") --> ' 1234.0'
format(1234, "8,1f") --> ' 1234,0'
format(1234, "8.,1f") --> ' 1.234,0'
format(1234, "8 ,f") --> ' 1 234,0'
format(1234, "8d") --> ' 1234'
format(1234, "8,d") --> ' 1,234'
format(1234, "8_d") --> ' 1_234'
This proposal meets mosts needs, but it comes at the expense
of taking a bit more effort to parse. Not every possible
convention is covered, but at least one of the options (spaces
or underscores) should be readable, understandable, and useful
to folks from many diverse backgrounds.
As shown in the examples, the *width* argument means the total
length including the thousands separators and decimal separators.
No change is proposed for the locale module.
The thousands separator is defined as shown above for types
'd', 'e', 'f', 'g', '%', 'E', 'G' and 'F'. To allow future
extensions, it is undefined for other types: binary, octal,
hex, character, etc.
The drawback to this alternative proposal is the difficulty
of mentally parsing whether a single separator is a thousands
separator or decimal separator. Perhaps it is too arcane
to link the decimal separator with the precision specifier.
Commentary
==========
* Some commenters do not like the idea of format strings at all
and find them to be unreadable. Suggested alternatives include
the COBOL style PICTURE approach or a convenience function with
keyword arguments for every possible combination.
* Some newsgroup respondants think there is no place for any
scripts that are not internationalized and that it is a step
backwards to provide a simple way to hardwire a particular choice
(thus reducing incentive to use a locale sensitive approach).
* Another thought is that embedding some particular convention in
individual format strings makes it hard to change that convention
later. No workable alternative was suggested but the general idea
is to set the convention once and have it apply everywhere (others
commented that locale already provides a way to do this).
* There are some precedents for grouping digits in the fractional
part of a floating point number, but this PEP does not venture into
that territory. Only digits to the left of the decimal point are
grouped. This does not preclude future extensions; it just focuses
on a single, generally useful extension to the formatting language.
* James Knight observed that Indian/Pakistani numbering systems
group by hundreds. Ben Finney noted that Chinese group by
ten-thousands. Eric Smith pointed-out that these are already
handled by the "n" specifier in the locale module (albeit only
for integers). This PEP does not attempt to support all of those
possibilities. It focuses on a single, relatively common grouping
convention that offers a quick way to improve readability in many
(though not all) contexts.
Copyright
=========
This document has been placed in the public domain.
..
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
coding: utf-8
End: