Steven D'Aprano <steve+pyt...@pearwood.info> added the comment:
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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue44355>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
