Refer to actual format string when creating “zero padding” error message

[bignose]

BPO	27772
Nosy	@ericvsmith, @serhiy-storchaka
PRs	bpo-27772: Make preciding width with 0 valid in string format. #11270

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2021-01-25.09:58:07.573>
created_at = <Date 2016-08-16.04:35:18.934>
labels = ['interpreter-core', '3.10']
title = 'Refer to actual format string when creating \xe2\x80\x9czero padding\xe2\x80\x9d error message'
updated_at = <Date 2021-01-25.09:58:07.570>
user = 'https://bugs.python.org/bignose'

bugs.python.org fields:

activity = <Date 2021-01-25.09:58:07.570>
actor = 'serhiy.storchaka'
assignee = 'none'
closed = True
closed_date = <Date 2021-01-25.09:58:07.573>
closer = 'serhiy.storchaka'
components = ['Interpreter Core']
creation = <Date 2016-08-16.04:35:18.934>
creator = 'bignose'
dependencies = []
files = []
hgrepos = []
issue_num = 27772
keywords = ['patch']
message_count = 3.0
messages = ['272827', '332271', '385611']
nosy_count = 3.0
nosy_names = ['eric.smith', 'bignose', 'serhiy.storchaka']
pr_nums = ['11270']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue27772'
versions = ['Python 3.10']

[bignose]

When using a format specifier with leading zero, the format spec mini-language (as documented at https://docs.python.org/3/library/string.html#format-specification-mini-language\>) says:

'=' […] becomes the default when ‘0’ immediately precedes the field width.

When the ‘=’ option is only implied, the error message “ValueError: '=' alignment not allowed in string format specifier” becomes surprising and incomprehensible to someone who does not know that implied behaviour.

In bpo-15560, Terry Reedy says:

If the spec string is still available, it could be searched and the message adjusted if '=' is not present. That proposal should be a new issue if someone wants to push it.

This issue raises that proposal.

The error message should be changed so that:

• It makes sense whether or not the ‘=’ option is explicit in the format specifier.

Or:

• Different messages are produced when the ‘=’ option is explicit versus when it is implicit.

I think the former option is better, but either will satisfy this request.

[serhiy-storchaka]

PR 11270 fixes this issue by making such format valid. Preceding the width field by '0' no longer affects the default alignment for strings, i.e. no longer sets the alignment to invalid '=' if it is not specified explicitly.

>>> format('abc', '<8')
'abc     '
>>> format('abc', '8')
'abc     '
>>> format('abc', '<08')
'abc00000'
>>> format('abc', '08')
'abc00000'

This does not contradict the documentation, which specifies this case for numeric types, but not for strings.

[serhiy-storchaka]

New changeset cf19cc3 by Serhiy Storchaka in branch 'master':
bpo-27772: Make preceding width with 0 valid in string format. (GH-11270)
cf19cc3