This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients christian.heimes, eric.smith, ewosborne, ncoghlan, serhiy.storchaka
Date 2018-02-24.04:35:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I think supporting "s" makes sense, as we're going to need to treat the empty format string as implying "s" for backwards compatibility reasons:

    >>> f"{v4}"

Right now, attempting to format that field without `!s` will give you a TypeError, but as Eric O notes, once IP addresses support __format__, we're going to have to choose between:

- raise an exception if formatting directions are given without a numeric typecode
- ignore the formatting in that case (which is what the current PR does)
- handle it the same way "!s" would (and also allow "s" as an explicit type code)

The last option sounds the most desirable to me, as that way we can just say "'s' is the default IP addressing formatting typecode" (similar to the way 'd' is the default for integers, and 'g' is the default for floating point numbers).

I *don't* think we should allow combining the numeric typecode with the string type code, though. The numeric types don't allow that, and f-strings already support nesting if you want to combine string formatting with numeric formatting:

    >>> f"{f'{42**100:g}':>20s}"
    '        2.11314e+162'
Date User Action Args
2018-02-24 04:35:51ncoghlansetrecipients: + ncoghlan, eric.smith, christian.heimes, serhiy.storchaka, ewosborne
2018-02-24 04:35:51ncoghlansetmessageid: <>
2018-02-24 04:35:51ncoghlanlinkissue32820 messages
2018-02-24 04:35:50ncoghlancreate