1. Forum
  2. Usenet
  3. COMP.LANG.PYTHON

  • f-string error message

    From Rob Cliffe@21:1/5 to All on Sun Aug 27 22:19:02 2023
    I am currently using Python 3.11.4.
    First I want to say: f-strings are great!  I use them all the time,
    mostly but by no means exclusively for debug messages.  And in 3.12 they
    will get even better.
    And the improved error messages in Python (since 3.9) are great too! 
    Keep up the good work.
    However the following error message confused me for a while when it
    happened in real code:

    import decimal
    x=42
    f"{x:3d}"
    ' 42'
    x=decimal.Decimal('42')
    f"{x:3d}"
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: invalid format string

    I understand that this is an error: I'm telling the f-string to expect
    an integer when in fact I'm giving it a Decimal.
    And indeed f"{x:3}" gives ' 42' whether x is an int or a Decimal.
    However, to my mind it is not the format string that is invalid, but the
    value supplied to it.
    Would it be possible to have a different error message, something like

    ValueError: int expected in format string but decimal.Decimal found

    Or am I missing something?
    Best wishes
    Rob Cliffe

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Random832@21:1/5 to Rob Cliffe via Python-list on Thu Aug 31 00:15:12 2023
    On Sun, Aug 27, 2023, at 17:19, Rob Cliffe via Python-list wrote:
    I understand that this is an error: I'm telling the f-string to expect
    an integer when in fact I'm giving it a Decimal.
    And indeed f"{x:3}" gives ' 42' whether x is an int or a Decimal.
    However, to my mind it is not the format string that is invalid, but the value supplied to it.
    Would it be possible to have a different error message, something like

    ValueError: int expected in format string but decimal.Decimal found

    Or am I missing something?

    It's up to the type what format strings are valid for it, so you can't really go "int expected". However, a more detailed error string like "invalid format string '3d' for object Decimal('42')" might be useful.

    right now we have some inconsistencies:
    - float object [same for str, int, etc]
    ValueError: Unknown format code 'd' for object of type 'float' [if it thinks it's identified a single-letter 'code' in the usual microlanguage]
    ValueError: Invalid format specifier '???' for object of type '[type]'
    - arbitrary object that doesn't override __format__, ipaddress
    TypeError: unsupported format string passed to [type].__format__
    - datetime, decimal
    ValueError: Invalid format string

    neither shows the value of the offending object, only its type. incidentally, ipaddress and object don't support the usual field width, padding, etc specifiers

    [int supports code 'f' just fine, by the way, but has the same message as float if you give it 's']

    Going beyond that, it *might* be viable to have some sort of "guess what numeric type the format string was intended for", shared across at least all numeric types of objects. Alternatively, we could require all numeric types to support all numeric
    formats, even ones that don't make a lot of sense.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)