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.