Removed references to previous 'fformat' proposal.
Added clarification about relationship with string.Template
This commit is contained in:
parent
d9b470db86
commit
2652ae46f8
58
pep-3101.txt
58
pep-3101.txt
|
@ -22,28 +22,29 @@ Rationale
|
|||
|
||||
Python currently provides two methods of string interpolation:
|
||||
|
||||
- The '%' operator for strings.
|
||||
- The '%' operator for strings. [1]
|
||||
|
||||
- The string.Template module.
|
||||
- The string.Template module. [2]
|
||||
|
||||
The scope of this PEP will be restricted to proposals for built-in
|
||||
string formatting operations (in other words, methods of the
|
||||
built-in string type). This does not obviate the need for more
|
||||
sophisticated string-manipulation modules in the standard library
|
||||
such as string.Template. In any case, string.Template will not be
|
||||
discussed here, except to say that the this proposal will most
|
||||
likely have some overlapping functionality with that module.
|
||||
|
||||
built-in string type).
|
||||
|
||||
The '%' operator is primarily limited by the fact that it is a
|
||||
binary operator, and therefore can take at most two arguments.
|
||||
One of those arguments is already dedicated to the format string,
|
||||
leaving all other variables to be squeezed into the remaining
|
||||
argument. The current practice is to use either a dictionary or a
|
||||
tuple as the second argument, but as many people have commented
|
||||
[1], this lacks flexibility. The "all or nothing" approach
|
||||
[3], this lacks flexibility. The "all or nothing" approach
|
||||
(meaning that one must choose between only positional arguments,
|
||||
or only named arguments) is felt to be overly constraining.
|
||||
|
||||
While there is some overlap between this proposal and
|
||||
string.Template, it is felt that each serves a distinct need,
|
||||
and that one does not obviate the other. In any case,
|
||||
string.Template will not be discussed here.
|
||||
|
||||
|
||||
Specification
|
||||
|
||||
|
@ -62,9 +63,9 @@ Specification
|
|||
|
||||
String Methods
|
||||
|
||||
The build-in string class will gain two new methods. The first
|
||||
method is 'format', and takes an arbitrary number of positional
|
||||
and keyword arguments:
|
||||
The build-in string class will gain a new method, 'format',
|
||||
which takes takes an arbitrary number of positional and keyword
|
||||
arguments:
|
||||
|
||||
"The story of {0}, {1}, and {c}".format(a, b, c=d)
|
||||
|
||||
|
@ -135,20 +136,6 @@ Format Strings
|
|||
and the matching right brace ('}') to the various underlying
|
||||
formatters (described later.)
|
||||
|
||||
When using the 'fformat' variant, it is possible to omit the field
|
||||
name entirely, and simply include the conversion specifiers:
|
||||
|
||||
"My name is {:pad(23)}"
|
||||
|
||||
This syntax is used to send special instructions to the custom
|
||||
formatter object (such as instructing it to insert padding
|
||||
characters up to a given column.) The interpretation of this
|
||||
'empty' field is entirely up to the custom formatter; no
|
||||
standard interpretation will be defined in this PEP.
|
||||
|
||||
If a custom formatter is not being used, then it is an error to
|
||||
omit the field name.
|
||||
|
||||
|
||||
Standard Conversion Specifiers
|
||||
|
||||
|
@ -303,7 +290,7 @@ Alternate Syntax
|
|||
string interpolation. The Microsoft .Net libraries uses braces
|
||||
({}), and a syntax which is very similar to the one in this
|
||||
proposal, although the syntax for conversion specifiers is quite
|
||||
different. [2]
|
||||
different. [4]
|
||||
|
||||
- Backquoting. This method has the benefit of minimal syntactical
|
||||
clutter, however it lacks many of the benefits of a function
|
||||
|
@ -314,6 +301,13 @@ Alternate Syntax
|
|||
on.
|
||||
|
||||
|
||||
Sample Implementation
|
||||
|
||||
A rought prototype of the underlying 'cformat' function has been
|
||||
coded in Python, however it needs much refinement before being
|
||||
submitted.
|
||||
|
||||
|
||||
Backwards Compatibility
|
||||
|
||||
Backwards compatibility can be maintained by leaving the existing
|
||||
|
@ -325,10 +319,16 @@ Backwards Compatibility
|
|||
|
||||
References
|
||||
|
||||
[1] [Python-3000] String formating operations in python 3k
|
||||
[1] Python Library Reference - String formating operations
|
||||
http://docs.python.org/lib/typesseq-strings.html
|
||||
|
||||
[2] Python Library References - Template strings
|
||||
http://docs.python.org/lib/node109.html
|
||||
|
||||
[3] [Python-3000] String formating operations in python 3k
|
||||
http://mail.python.org/pipermail/python-3000/2006-April/000285.html
|
||||
|
||||
[2] Composite Formatting - [.Net Framework Developer's Guide]
|
||||
[4] Composite Formatting - [.Net Framework Developer's Guide]
|
||||
http://msdn.microsoft.com/library/en-us/cpguide/html/cpconcompositeformatting.asp?frame=true
|
||||
|
||||
|
||||
|
|
Loading…
Reference in New Issue