int and float should detect inconsistent format strings

[tiran]

BPO	17247
Nosy	@mdickinson, @ericvsmith, @tiran, @ezio-melotti, @bitdancer
Files	issue17247.diff

^{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 = None
created_at = <Date 2013-02-19.22:24:53.542>
labels = ['interpreter-core', 'type-bug']
title = 'int and float should detect inconsistent format strings'
updated_at = <Date 2015-04-09.21:08:28.439>
user = 'https://github.com/tiran'

bugs.python.org fields:

activity = <Date 2015-04-09.21:08:28.439>
actor = 'r.david.murray'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2013-02-19.22:24:53.542>
creator = 'christian.heimes'
dependencies = []
files = ['30417']
hgrepos = []
issue_num = 17247
keywords = ['patch']
message_count = 7.0
messages = ['182447', '182449', '182450', '182451', '182452', '190331', '240391']
nosy_count = 5.0
nosy_names = ['mark.dickinson', 'eric.smith', 'christian.heimes', 'ezio.melotti', 'r.david.murray']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue17247'
versions = ['Python 3.5']

Linked PRs

• gh-61449: document present 0-padding option behavior for builtin numeric types #145748
• gh-61449: handle 0-padding option for Fractions like for floats #145765
• gh-61449: handle 0-padding option for Decimals like for floats #145771

[tiran]

>>> "{:<06}".format(1.2)
'1.2000'
>>> "{:<06}".format(decimal.Decimal(1.2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid format string

[skrah]

3.2 has a better error message:

>>> "{:<06}".format(Decimal("1.2"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/decimal.py", line 3632, in __format__
    spec = _parse_format_specifier(specifier, _localeconv=_localeconv)
  File "/usr/lib/python3.2/decimal.py", line 5600, in _parse_format_specifier
    "format specifier: " + format_spec)
ValueError: Alignment conflicts with '0' in format specifier: <06

That's because '0' already has a special meaning:

"Preceding the width field by a zero ('0') character enables sign-aware zero-padding for numeric types. This is equivalent to a fill character of '0' with an alignment type of '='."

[tiran]

The output is from Python 3.3. Why has Python 3.3 a less informative error message than 3.2?

I also wonder why it works with floats if it has a special meaning? Either float or Decimal is broken.

[skrah]

Christian Heimes <report@bugs.python.org> wrote:

The output is from Python 3.3. Why has Python 3.3 a less informative error message than 3.2?

Because the error is discovered in libmpdec and it would require a significant
amount of work to provide fine-grained error messages.

I also wonder why it works with floats if it has a special meaning?
Either float or Decimal is broken.

Yes, IMO float should detect the ambiguity. You see that the zero implies left
padding:

>>> "{:06}".format(1.2)
'0001.2'

And in case of a conflict right padding wins:

>>> "{:<06}".format(1.2)
'1.2000'

The unambiguous way to get right padding is:

>>> "{:0<6}".format(Decimal("1.2"))
'1.2000'

>>> "{:X<6}".format(Decimal("1.2"))
'1.2XXX'

[skrah]

With int and float it's also possible to specify both conflicting
alignments and fill characters:

 >>> "{:x<06}".format(1.2)
'1.2xxx'

So I really think that the builtins should be changed to detect
the conflict.

[skrah]

With this patch float and int should behave like Decimal. It may
break existing code that (accidentally) uses both legacy zero padding
and explicit alignment.

[bitdancer]

This would need a deprecation preriod if we want to do it.

[erlend-aasland]

@mdickinson: Do you have an opinion regarding this? Is it worth it to change the behaviour?

[ericvsmith]

I don't think we can change the behavior at this point. It's probably worth documenting, though.