Format strings should allow spaces around keys and indices. This might be as simple as running str.strip() on the contents of curly braces?

Aside from indentation and newlines, in most other contexts whitespace is insignificant. E.g. in subscripting `seq[ index ]`. But format strings treat spaces as part of the index or key, which is surprising.

f-strings, on the other hand, already allow spaces around expressions and keys:

    >>> name = 'Brian'
    >>> f'{ name.upper() }'
    'BRIAN'


Examples:

    '{ }'.format(30)
    Expect to get '30'
    but get KeyError: ' '


    '{ 0 }'.format(30)
    Expect to get '30'
    but get KeyError: ' 0 '

    '{ x }'.format(x=30)
    Expect to get '30'
    but get KeyError: ' x '


See discussion here:

https://discuss.python.org/t/please-help-key-error/9168/1

The problem with this change is that it wouldn't be backward compatible. I'm not sure how many people it would affect, but probably more than zero.

>>> str.format('{ 0 }', **{' 0 ': 42})
'42'

>>> str.format('{ }', **{' ': 43})
'43'

Does that mean it can't be changed? Not necessarily, of course.

I agree it's unfortunate that we didn't specify this back with PEP 3101.

Syntax of format strings cannot be the same as in f-strings. {0} means the first positional argument in format string an integer literal 0 in f-string. {a[x]} means the value of literal string key "x" of keyword argument a in format string, and indexing variable a with variable index/key x in f-string. Such things as {if}, {+.name} or {0[-]} are not even valid in f-strings.

Since we cannot get rid of all differences between format strings and f-strings, I do not think that this one change is worth. It will only make differences more complex. Not mentioning that it is a compatibility breaking change, and can break user code.

I agree that we cannot make the syntax of format string identifal to
f-strings. F-strings support arbitrary expressions, while format strings 
support only a small subset of possible identifiers.

My comment was not to make format strings identical to f-strings, which 
would be impossible, but to point out that whitespace around identifiers 
and indices is not significant in most contexts, including f-strings.

* in code `1 + a [ key ]` is the same as `1+a[key]`
* the name ` spam ` is the same as `spam`
* in f-strings `f'{ spam }'` and `f'{spam}'` are the same

etc. Places (apart from indentation and newlines) where whitespace has 
meaning is very rare. But inside format braces it is treated as 
significant.

In a format string, we cannot make spaces part of the keyword parameter:

    '{ } { 1 } { x }'.format(' '=20, ' 1 '=30, ' x '=40)

is not valid syntax.

I think that, for the format method, any whitespace in the `{}` will 
prevent the method from working and will raise KeyError. Unless I have 
missed something, I think that it is *impossible* for anyone to use 
spaces in the format method without an exception, and so it is safe for 
us to change the behaviour.

Right now, the only reason spaces will appear inside the braces of a 
format string will be by mistake, which will raise. So unless I have 
missed something, this would be a safe enhancement for the `format` 
method that would make format strings behave more like other parts of 
Python code. One less surprise.

The format_map method is a little bit different:

    >>> '{ x }'.format_map({'x': 10, ' x ': 20})
    '20'

So it is *possible*, but unlikely, that people are using keys with 
spaces in format_map calls. So we have some alternatives:

1. Reject this enhancement and do nothing.

2. Have the format method alone strip spaces, and format_map preserve 
   them. This would be backwards compatible, but a surprising 
   difference between the two methods.

3. Give format_map a keyword-only parameter, "preserve_spaces". The 
   format method will always strip spaces; format_map will only strip 
   them if the preserve_spaces parameter is False.

4. Probably nobody is *actually* using spaces in format_map either. It
   would be a very unusual and rare thing to do. So maybe we break
   backwards compatibility and don't bother with the extra keyword 
   parameter.

I think that option 3, with a default of True, would be safe. Option 3 
with a default of False would technically break backwards compatibility, 
but would allow people who wanted the old behaviour to get it. Since I 
doubt that there are many people, I think that option 3 with a default 
of False is acceptable.

See msg395383 for how it's an incompatible change even to .format().

In the 15 years since I implemented .format(), this is the first I've ever heard of someone being confused by adding extra spaces. I don't think it's worth changing this.

Maybe leave the current state, keeping backwards compatibility, but improve the error message by adding "perhaps you wanted no spaces in the format field?" when the_field.replace(" ", "") would be valid?