Updated Pep 3101 to reflect typos and other small errors found by Mark Summerfield (and a few by myself)

pep-3101.txt

@@ -120,9 +120,8 @@ Format Strings
     Character data is data which is transferred unchanged from the
     format string to the output string; markup is not transferred from
     the format string directly to the output, but instead is used to
-    define 'replacement fields' that describes to the format engine
-    what should be placed in the output string in the place of the
-    markup.
+    define 'replacement fields' that describe to the format engine
+    what should be placed in the output string in place of the markup.
 
     Brace characters ('curly braces') are used to indicate a
     replacement field within the string:
@@ -156,7 +155,7 @@ Simple and Compound Field Names
     A compound field name is a combination of multiple simple field
     names in an expression:
 
-        "My name is {0.name}".format(file('out.txt'))
+        "My name is {0.name}".format(open('out.txt', 'w'))
 
     This example shows the use of the 'getattr' or 'dot' operator
     in a field expression.  The dot operator allows an attribute of
@@ -177,19 +176,21 @@ Simple and Compound Field Names
     is much more limited than its conventional usage.  In the above example,
     the string 'name' really is the literal string 'name', not a variable
     named 'name'.  The rules for parsing an item key are very simple.
-    If it starts with a digit, then its treated as a number, otherwise
+    If it starts with a digit, then it is treated as a number, otherwise
     it is used as a string.
 
-    It is not possible to specify arbitrary dictionary keys from
-    within a format string.
+    Because keys are not quote-delimited, it is not possible to
+    specify arbitrary dictionary keys (e.g., the strings "10" or
+    ":-]") from within a format string.
 
     Implementation note: The implementation of this proposal is
-    not required to enforce the rule about a name being a valid
-    Python identifier.  Instead, it will rely on the getattr function
-    of the underlying object to throw an exception if the identifier
-    is not legal.  The str.format() function will have a minimalist
-    parser which only attempts to figure out when it is "done" with an
-    identifier (by finding a '.' or a ']', or '}', etc.).
+    not required to enforce the rule about a simple or dotted name
+    being a valid Python identifier.  Instead, it will rely on the
+    getattr function of the underlying object to throw an exception if
+    the identifier is not legal.  The str.format() function will have
+    a minimalist parser which only attempts to figure out when it is
+    "done" with an identifier (by finding a '.' or a ']', or '}',
+    etc.).
 
 
 Format Specifiers
@@ -202,15 +203,15 @@ Format Specifiers
         "My name is {0:8}".format('Fred')
 
     The meaning and syntax of the format specifiers depends on the
-    type of object that is being formatted, however there is a
-    standard set of format specifiers used for any object that
-    does not override them.
+    type of object that is being formatted, but there is a standard
+    set of format specifiers used for any object that does not
+    override them.
 
     Format specifiers can themselves contain replacement fields.
     For example, a field whose field width is itself a parameter
     could be specified via:
 
-        "{0:{1}}".format(a, b, c)
+        "{0:{1}}".format(a, b)
 
     These 'internal' replacement fields can only occur in the format
     specifier part of the replacement field.  Internal replacement fields
@@ -232,14 +233,14 @@ Format Specifiers
 
 Standard Format Specifiers
 
-    If an object does not define its own format specifiers, a
-    standard set of format specifiers are used.  These are similar
-    in concept to the format specifiers used by the existing '%'
-    operator, however there are also a number of differences.
+    If an object does not define its own format specifiers, a standard
+    set of format specifiers is used.  These are similar in concept to
+    the format specifiers used by the existing '%' operator, however
+    there are also a number of differences.
 
     The general form of a standard format specifier is:
 
-        [[fill]align][sign][0][width][.precision][type]
+        [[fill]align][sign][0][minimumwidth][.precision][type]
 
     The brackets ([]) indicate an optional element.
 
@@ -264,8 +265,8 @@ Standard Format Specifiers
     pad the field to the minimum width.  The fill character, if present,
     must be followed by an alignment flag.
 
-    The 'sign' option is only valid for number types, and can be one of
-    the following:
+    The 'sign' option is only valid for numeric types, and can be one
+    of the following:
 
         '+'  - indicates that a sign should be used for both
                positive as well as negative numbers
@@ -284,7 +285,7 @@ Standard Format Specifiers
 
     The 'precision' is a decimal number indicating how many digits
     should be displayed after the decimal point in a floating point
-    conversion.  For non-number types the field indicates the maximum
+    conversion.  For non-numeric types the field indicates the maximum
     field size - in other words, how many characters will be used from
     the field content.  The precision is ignored for integer conversions.
 
@@ -294,7 +295,7 @@ Standard Format Specifiers
 
         'b' - Binary. Outputs the number in base 2.
         'c' - Character. Converts the integer to the corresponding
-              unicode character before printing.
+              Unicode character before printing.
         'd' - Decimal Integer. Outputs the number in base 10.
         'o' - Octal format. Outputs the number in base 8.
         'x' - Hex format. Outputs the number in base 16, using lower-
@@ -333,9 +334,9 @@ Standard Format Specifiers
         "Today is: {0:a b d H:M:S Y}".format(datetime.now())
 
     For all built-in types, an empty format specification will produce
-    the same result as would have been produced by calling str(value).
-    It is recommended that objects defining their own format specifiers
-    follow this convention as well.
+    the equivalent of str(value).  It is recommended that objects
+    defining their own format specifiers follow this convention as
+    well.
 
 
 Explicit Conversion Flag
@@ -426,11 +427,11 @@ User-Defined Formatting
     lives in the 'string' module.  This class takes additional options
     which are not accessible via the normal str.format method.
     
-    An application can subclass the Formatter class to create their
-    own customized formatting behavior.
+    An application can subclass the Formatter class to create its own
+    customized formatting behavior.
 
     The PEP does not attempt to exactly specify all methods and
-    properties defined by the Formatter class; Instead, those will be
+    properties defined by the Formatter class; instead, those will be
     defined and documented in the initial implementation.  However, this
     PEP will specify the general requirements for the Formatter class,
     which are listed below.
@@ -456,8 +457,8 @@ Formatter Methods
         -- vformat(format_string, args, kwargs)
         
     'format' is the primary API method.  It takes a format template,
-    and an arbitrary set of positional and keyword argument.  'format'
-    is just a wrapper that calls 'vformat'.
+    and an arbitrary set of positional and keyword arguments.
+    'format' is just a wrapper that calls 'vformat'.
 
     'vformat' is the function that does the actual work of formatting.  It
     is exposed as a separate function for cases where you want to pass in
@@ -484,7 +485,7 @@ Formatter Methods
     positional arguments.
     
     For compound field names, these functions are only called for the
-    first component of the field name; Subsequent components are handled
+    first component of the field name; subsequent components are handled
     through normal attribute and indexing operations.
     
     So for example, the field expression '0.name' would cause 'get_value'
@@ -606,9 +607,9 @@ Customizing Formatters
     It would also be possible to create a 'smart' namespace formatter
     that could automatically access both locals and globals through
     snooping of the calling stack.  Due to the need for compatibility
-    the different versions of Python, such a capability will not be
-    included in the standard library, however it is anticipated that
-    someone will create and publish a recipe for doing this.
+    with the different versions of Python, such a capability will not
+    be included in the standard library, however it is anticipated
+    that someone will create and publish a recipe for doing this.
 
     Another type of customization is to change the way that built-in
     types are formatted by overriding the 'format_field' method.  (For
@@ -663,9 +664,9 @@ Alternate Syntax
 
       This scheme is generally used in cases where interpolation is
       implicit - that is, in environments where any string can contain
-      interpolation variables, and no special subsitution function
+      interpolation variables, and no special substitution function
       need be invoked.  In such cases, it is important to prevent the
-      interpolation behavior from occuring accidentally, so the '$'
+      interpolation behavior from occurring accidentally, so the '$'
       (which is otherwise a relatively uncommonly-used character) is
       used to signal when the behavior should occur.
 
@@ -674,7 +675,7 @@ Alternate Syntax
       taken to prevent accidental interpolation, in which case a
       lighter and less unwieldy syntax can be used.
 
-    - Printf and its cousins ('%'), including variations that add a
+    - printf and its cousins ('%'), including variations that add a
       field index, so that fields can be interpolated out of order.
 
     - Other bracket-only variations.  Various MUDs (Multi-User
@@ -731,7 +732,7 @@ Alternate Feature Proposals
     the parameter before it's passed in to the formatting function.
     For cases where the format string is being use to do arbitrary
     formatting in a data-rich environment, it's recommended to use
-    a templating engine specialized for this purpose, such as
+    a template engine specialized for this purpose, such as
     Genshi [5] or Cheetah [6].
     
     Many other features were considered and rejected because they
@@ -744,14 +745,14 @@ Security Considerations
 
     Historically, string formatting has been a common source of
     security holes in web-based applications, particularly if the
-    string templating system allows arbitrary expressions to be
+    string formatting system allows arbitrary expressions to be
     embedded in format strings.
 
     The best way to use string formatting in a way that does not
     create potential security holes is to never use format strings
     that come from an untrusted source.
     
-    Barring that, the next best approach is to insure that string
+    Barring that, the next best approach is to ensure that string
     formatting has no side effects.  Because of the open nature of
     Python, it is impossible to guarantee that any non-trivial
     operation has this property.  What this PEP does is limit the